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Preface 


Apart from 

the many other fields that are incorporated in this process, it's also a realm where 
that 

there's nothing new under the sun, ground-breaking ideas are still cemented in this 
11 make 

us feel child-like excitement yet again. 

Getting started with game programming is easier now than ever before! 
e who 

actually put together libraries of code that can be used to eliminate the redundant 
or diffi, one 
t is the focal 

point of this publication. 

h, with each 
11 start 

with a basic clone of the classical arcade gam e — Snake, which introduces the basics 
of SFML and some of the framework that is going to persist until the very end. As 
difficult subjects are addressed, we will begin to cobble the second project together, 
his book focus 

on building and polishing an online RPG-style game that can be played with your 
friends! No detail of any of these projects will remain undiscussed, as you will be 
gle 

aspect of these projects. 

u away yet, 
ortions. 

So don't let the odds intimidate you. We hope to see you at the finish line! 
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What this book covers 

Chapter 1, It's Alive! It's Alive! - Setup and First Program, covers the fundamentals 
that are necessary in order to build basic SFML applications. 

Chapter 2, Give It Some Structure - Building the Game Framework, introduces a better 
framework for the applications that will be used throughout the book. It also covers 
the basics of timing in video games. 

Chapter 3, Get Your Hands Dirty - What You Need to Know, helps solidify all the 
information from the previous chapters by finishing our first game project. 

Chapter 4, Grab Tlwt Joystick - Input and Event Management, elaborates on the process 
it in an 

automated way. 

Chapter 5, Can I Pause Tins? - Application States, addresses the issue of state switching 
and blending using a state machine. 

Chapter 6, Set It in Motion! - Animating and Moving around Your World, deals with 
the issues of screen scrolling and resource management as well as the usage and 
animation of sprite sheets. 

Chapter 7, Rediscovering Fire - Common Game Design Elements, wraps up the second 
project of the book by dealing with entity management, tile-maps, and collision. 

Chapter 8, Tire More You Know - Common Game Programming Patterns, introduces 
the third project of the book by covering the fundamentals of a few common 
programming patterns, including the entity component system. 

Chapter 9, A Breath of Fresh Air - Entity Component System Continued, focuses on 
building common game functionality by breaking it down to its components 
and systems. 

Chapter 10, Can I Click This? - GUI Fundamentals, breaks down how a graphical user 
interface can be implemented using the fundamental data types. 

Chapter 11, Don't Touch the Red Button! - Implementing the GUI, picks up where the 
m. We 

also discuss three basic element types. 

Chapter 12, Can You Hear Me Now? - Sound and Music, livens up the third project of 
the book by bringing entity sounds and music to the table. 
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Chapter 13, We Have Contact! - Networking Basics, covers all the basics that are 
required in order to implement networking in our final project. 

Chapter 14, Come Play with Us! - Multiplayer Subtleties, transforms the final project 
of the book into a multiplayer RPG-style death match with the application of a 
client-server network model as well as a combat system. 

What you need for this book 

downloaded 

and set up. Chapter 1, It's Alive! It's Alive! - Setup and First Program covers this 
process step by step. 

Additionally, a compiler or an IDE that supports C++11 is needed in order to 
en written 

on and compiled with the Microsoft Visual Studio 2013 IDE on a system that runs 
Windows 7. 


Who this book is for 

a decent 
game design. 


Conventions 

In this book, you will find a number of text styles that distinguish between different 
kinds of information. Here are some examples of these styles and an explanation of 
their meaning. 

Code words in text, database table names, folder names, filenames, file extensions, 
pathnames, dummy URLs, user input, and Twitter handles are shown as follows: 
"We can include other contexts through the use of the include directive." 

A block of code is set as follows: 

#include <SFML/Graphics . hpp> 

void main(int argc, char** argv[]){ 


} 
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, the 

relevant lines or items are set in bold: 
ttinclude <SFML/Graphics . hpp> 

void main(int argc, char** argv[]){ 


} 

New terms and important words are shown in bold. Words that you see on the 
his: "Navigate 

to the VC++ Directories underneath Configuration Properties by right clicking on 
our project and selecting Properties." 

Warnings or important notes appear in a box like this. 


Tips and tricks appear like this. 


Reader feedback 

Feedback from our readers is always welcome. Let us know what you think about 
r us as it 

helps us develop titles that you will really get the most out of. 

To send us general feedback, simply e-mail f eedback@packtpub . com, and mention 
the book's title in the subject of your message. 

If there is a topic that you have expertise in and you are interested in either writing 
or contributing to a book, see our author guide at www . packtpub . com/ authors. 

Customer support 

Now that you are the proud owner of a Packt book, we have a number of things to 
help you to get the most from your purchase. 
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Downloading the example code 

You can download the example code files from your account at http : //www . 
packtpub . com for all the Packt Publishing books you have purchased. If you 
purchased this book elsewhere, you can visit http : / /www . packtpub . com/ support 
and register to have the files e-mailed directly to you. 

Errata 

mistakes 

do happen. If you find a mistake in one of our books — maybe a mistake in the text or 
g so, you can 

save other readers from frustration and help us improve subsequent versions of this 
book. If you find any errata, please report them by visiting http : / /www . packtpub . 
com/submit-errata, selecting your book, clicking on the Errata Submission Form 
link, and entering the details of your errata. Once your errata are verified, your 
te or added 

to any list of existing errata under the Errata section of that title. 

To view the previously submitted errata, go to https : //www . packtpub . com/books/ 
content/support and enter the name of the book in the search field. The required 
information will appear under the Errata section. 

Piracy 

oss all 

ry seriously. 

If you come across any illegal copies of our works in any form on the Internet, please 
provide us with the location address or website name immediately so that we can 
pursue a remedy. 

Please contact us at copyright@packtpub . com with a link to the suspected 
pirated material. 

We appreciate your help in protecting our authors and our ability to bring you 
valuable content. 

Questions 

t 

quest ions@packtpub . com, and we will do our best to address the problem. 
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It's Alive! It's Alive! - Setup 

and First Program 


the thrill 

of exploration, it hardly makes it difficult to narrow down why most of our fellow 
game developers do what they do. Although creation is a major force in this process, 
us will be placed 
given project, 

but maybe even kills the motivation to work on it. Having a good resource to fall 
back on is crucial during those times, especially for new developers who are just 
now getting their hands dirty, and that's where we come in. Our goal is to pass on 
during 

the course of this book. 

In this chapter, we're going to be covering: 

• Setting up SFML on your machine and IDE 

• Flow of an average SFML application 

• Opening and managing windows 

• Basics of rendering 

g games using 

Simple and Fast Multimedia Library (SFML). Let's get started by first tackling the 
setup process! 
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What is SFML? 

Before we start throwing terms and code your way, it's only fair we talk a little bit 
about the choice library for this book. As its title clearly states, SFML is a library, which 
speeds up and eases the process of developing applications that rely on extensive 
use of media content, such as video, text, still images, audio, and animation for 
interactivity, and we will be focusing on a specific category of those applications, that 
is, video games. It provides an easy to use application programming interface (API), 
compiles and runs out of the box on Windows, Linux, and Mac OS X, and is supported 
by multiple languages, such as C, .NET, C++, Java, Ruby, Python, and Go, just to name 
a few. Unofficial ports for certain mobile devices do exist out there, however official 
releases for mobile platforms are still in the works. It's also open source, so one can 
always go and look at the source code if one is so inclined. In this book, we will be 
focusing solely on development for the Windows platform using C++11. 

For convenience, SFML is split into five modules, which are independent of one 
another and can be included on a need-to-use basis: 

• System: A core module, which defines most basic data structures, provides 
access to threads, clocks, user data streams, and other essentials. 

• Window: This module provides a means of creating and managing 
a window, gathering user input and events, as well as using SFML 
alongside OpenGL. 

• Graphics: Everything left to be desired graphically after fully utilizing 
the window module falls back on the graphics module. It deals with 
everything concerning two-dimensional rendering. 

• Audio: Anything to do with playing music, sounds, audio streams, or 
recording audio is handled by this module. 

• Network: The last but definitely not the least interesting module that covers 
protocols. 

Each one of these modules is compiled in a separate library (.lib) with specific 
postfixes that signify whether the library is being linked statically or dynamically, as 
well as if it's being built in debug or release mode. Linking a library statically simply 
king, where 
. dl 1 filatter 

situation reduces the overall size of the application by relying on the library being 

present on the machine that runs it. It also means that the library can be upgraded 

without the need to alter the application, which can be useful when fixing bugs. 

vironments 

that are more limited. 
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It's also important to make sure that your application is being built in a mode that's 
itional 

information that is useful when you're hunting down flaws in your programs, 
for any 

other purposes than testing. When building your project in release mode, tons 
smaller 

executable footprint, but also a much faster running speed. This should be the 
of use other 
than debugging. 

Each module is named according to the format sfml-module [ - s] [ -d] . lib. For 
example, the file name of a graphics library that is being linked statically and 
compiled in debug mode would look like this: sfml-graphics-s-d. lib. When 
linking dynamically or compiling in release mode, the postfixes need to be omitted. 
SFML also requires the sfml_static macro to be defined when linking statically, 
which we will cover shortly when setting up our first project. 

An important thing to keep in mind about the separate libraries is that they still have 
dependencies. Window, graphics, audio, and network libraries are dependent on 
o compile 
o all three 
etworking 

libraries only depend on the system library. 

Since version 2.2, when linking SFML statically, its dependencies must 
also be linked to the project. These dependencies vary between major 
hat 

is, 2.3. The graphics library requires opengl32 . lib, f reetype . lib, 
and jpeg . lib libraries. The window library depends on opengl32 . 
lib, winmm. lib, and gdi32 . lib. Linking to the system library only 
requires the winmm. lib library, while sfml-network-s . lib relies 
on ws2_32 . lib in order to work. Lastly, the sound library depends 
on openal32 . lib, f lac . lib, vorbisenc . lib, vorbisf ile . lib, 
vorbis . lib, and ogg . lib. 

Each one of these five modules has a corresponding header that must be included 
to utilize its functionality. For example, including the graphics header would look 
like this: 

#include <SFML/Graphics . hpp> 
fying the 

actual header that is desired within a module: 

#include <SFML/Graphics/Color . hpp> 
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cessary. 



erent 

operating systems do not recognize paths that have a backslash in them. 


] 


SFML licensing 

Whenever you're utilizing a library of any sorts for your project, it's important 
lib/ 

use SFML 

for any purposes, even commercial applications, as well as alter and re-distribute 
it, given that the credit for writing the original software is left unchanged and the 
inal software 


opensource . org/licenses/Zlib. 


http : / / 


Resources and installation 

You can download the latest stable pre-built version of the library at: http : / /www . 
sf ml -dev . org/download . php. It is also possible for you to get the latest Git revision 
and compile it yourself from here: https: //github . com/LaurentGomila/SFML. The 
former option is easier and recommended for beginners. You have to wait for major 
self, you 
+ Makefiles, 

depending on the software that will be used to compile it. The official SFML website 
provides tutorials on building it yourself at: http : //www. sfml-dev.org/tutorials. 

After either obtaining the pre-built version of SFML or compiling it yourself, it's a 
good idea to move it somewhere more permanent, hopefully with a short path. It's 
ill hold 

SFML and potentially other libraries, which can be linked to quickly and at all times. 
This becomes useful when dealing with several versions of the same library as well, 
ry and header 

directories to be at C:\libs\SFML-2 . 3, consequently being C:\libs\SFML-2 . 3\ 
lib and c : \libs\SFML-2 . 3\include. These directories have to be set up correctly 
crosoft Visual 
setting up 

projects for Code::Blocks can be found in the tutorials section of the SFML website. 
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Setting up a Microsoft Visual Studio project 

nsole 
w is often 
avoid any 
SFML: 

1. Navigate to the VC++ Directories underneath Configuration Properties by 
right clicking on our project and selecting Properties. 

2. Only two fields are of any concern to us, the Include Directories and Library 
Directories. Make sure the paths to the SFML library and include directories 
are provided for both Debug and Release configurations. 

3. When linking SFML statically, the Preprocessor section underneath C/C++ is 
where you need to define the sfml_static macro. 

4. Next is the Additional Library Directories in General underneath Linker. 
Make sure that it also points to the SFML library directory in both debug 
and release configurations. 

5. Lastly, we need to set up the project dependencies by editing the Additional 
Dependencies field in the Input section underneath Linker. It would look 
something like this for the debug configuration when using statically linked 
libraries: sfml-graphics-s-d. lib; sfml-window-s-d. lib; sfml- 
system-s-d. lib; opengl32 . lib; f reetype . lib; jpeg. lib; winmm. 
lib; gdi32.1ib; 

Remember that we need to include the system library because of library 
dependencies. Also note the use of -s and -d postfixes. Make sure 
both debug and release configurations are set up and that the release 
configuration omits the -d postfix. 

Opening a window 

e 

window! 

Let's start out as usual by adding a file to our project, named Main . cpp. This will be 
the entry point to our application. The bare bones of a basic application look like this: 

ttinclude <SFML/Graphics . hpp> 


void main(int argc, char** argv[]){ 


} 
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vide us 
er ado, 

let's take a look at the code that opens our window: 

#include <SFML/Graphics . hpp> 

void main(int argc, char** argv[]){ 

sf : : RenderWindow window (sf : : VideoMode (640 , 480) , 

"First window!"); 

while (window . isOpen ( ) ) { 
sf:: Event event; 

while (window . pollEvent (event) ) { 

if (event . type == sf :: Event :: Closed) { 

// Close window button clicked, 
window . close ( ) ; 

} 

} 

window . clear ( sf : : Color : : Black) ; 

// Draw here, 
window. display () ; 

} 

} 

SFML uses the sf namespace, so we have to prefix its data types, 
enumerations, and static class members with an "sf : : 

The fiype 

RenderWindow. In this case, we used its constructor, however it is possible to leave it 
blank and utilize its create method later on by passing in the exact same arguments, 
of which it can take as little as two: an sf : : videoMode and anstd: :string title for 
the window. The video mode's constructor takes two arguments: the inner window 
th in bits 
ng fitting 

our purposes, so let's not lose sleep over that now. 
utilizes one 

of our window methods to check if it's still open, isOpen. This effectively creates our 
game loop, which is a central piece of all of our code. 



[ 6 ] 


Chapter 1 


Let's take a look at a diagram of a typical game: 



game world 
nges, 

and so on, and finally draw everything on the screen. This process needs to be 
repeated many times a second until the window is closed. The amount of times 
varies from application to application, sometimes going as high as thousands of 
iterations per second. Chapter 2, Give It Some Structure - Building the Game Framework 
11 as 

making the game run at constant speeds. 

Most applications need to have a way to check if a window has been closed, resized, 
or moved. That's where event processing comes in. SFML provides an event class that 
we can use to store our event information. During each iteration of our game loop, we 
need to check for the events that took place by utilizing the poll Event method of our 
window instance and process them. In this case, we're only interested in the event that 
gets dispatched when a mouse clicks on the close window button. We can check if the 
public member type of class Event matches the proper enumeration member, in this 
case it's sf : : Event : : Closed. If it does, we can call the close method of our window 
instance and our program will terminate. 
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Events must be processed in all SFML applications. Without the event 
loop polling events, the window will become unresponsive, since it 

window itself a way to handle its internal events as well, which is a 
necessity for it to react to being moved or resized. 


revious 
eking and 
something 
rabbing the 

eraser, however, we need to call the clear method of our window instance, which 
takes a sf : : Color data type as an argument and defaults to the color black if an 
argument isn't provided. The screen can be cleared to any of its enumerated colors 
that the sf : : Color class provides as static members or we can pass an instance of 
sf : : Color, which has a constructor that takes unsigned integer values for individual 
us a way to 

explicitly specify the color of our desired range, like so: 
window . clear ( sf : : Color (0,0,0,255) ) ; 

Finally, we call the window . display ( ) method to show everything that was drawn, 
n games 
stantly, but 

instead to a hidden buffer which then gets copied to our window once display is 
tearing, which 

occurs due to video card drivers pulling from the frame buffer while it's still being 
written to, resulting in a partially drawn image being displayed. Calling the display 
method is mandatory and cannot be avoided, otherwise the window will show up as 
a static square with no changes taking place. 

Remember to include SFML library .dll files in the same directory as 
your executable relies, provided the application has been dynamically 
linked. 

Upon compilation and execution of the code, we will find ourselves with a blank 
console window and a black 640x480 px window sitting over it, fewer than 20 lines 
of code, and an open window. Not very exciting, but it's still better than E.T. for 
Atari 2600. Let's draw something on the screen! 
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Basics of SFML drawing 

Much like in kindergarten, we will start with basic shapes and make our way up to 
more complex types. Let's work on rendering a rectangle shape by first declaring it 
and setting it up: 

sf : : RectangleShape rectangle ( sf : : Vector2f (128. Of, 128. Of) ) ; 
rectangle . setFillColor ( sf : :Color: :Red) ; 
rectangle . set Posit ion (320,240) ; 

sf : : RectangleShape is a derived class of sf : : Shape that inherits from 

sf : : Drawable, which is an abstract base class that all entities must inherit from 

een. It also 

inherits from sf : : Transformable, which provides all the necessary functionality in 
order to move, scale, and rotate an entity. This relationship allows our rectangle to be 
transformed, as well as rendered to the screen. In its constructor, we've introduced 
a new data type: sf : :Vector 2 f. It's essentially just a struct of two floats, x and y, 
with the 

std: : vector, which is a data container. 


SFML provides a few other vector types for integers and unsigned 
integers: sf : :Vector2i and sf : : Vector2u. The actual sf : :Vector2 
so: 

sf : : Vector2<long> m_vector; 

The rectangle constructor takes a single argument of sf: :Vector 2 f which represents 
we set the fill 

color of the rectangle by providing one of SFML's predefined colors this time. Lastly, 
we set the position of our shape by calling the setPosition method and passing its 
position in pixels alongside the x and y axis, which in this case is the centre of our 
ngle: 

window . draw ( rectangle) ; // Render our shape. 
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This line goes right before we call window . display ( ) ; and is responsible for 
take a 

look at the result: 



d. This is 

because the default origin of any sf : : Transformable, which is just a 2D point that 
s (0,0), which 
of this rectangle 
by calling the 

setOrigin method and passing in the desired local coordinates of our shape that 
will represent the new origin, which we want to be right in the middle: 

rectangle . setOrigin (64 . Of , 64 . Of ) ; 

ss provides a 

nice method getsize, which returns afloat vector containing the size: 

rectangle . setOrigin (rectangle . getSize (). x / 2, rectangle .getsize () .y / 
2 ) ; 
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The entire 
his: 


#include <SFML/Graphics . hpp> 

void main(int argc, char** argv[]){ 

sf : : RenderWindow window ( sf : : VideoMode (640,480) , 

"Rendering the rectangle."); 

// Creating our shape. 

sf : : RectangleShape rectangle ( sf : : Vector2f (128. Of, 128. Of) ) ; 
rectangle . setFillColor ( sf ; : Color: :Red) ; 
rectangle . set Posit ion (320,240) ; 
rectangle . setOrigin ( rectangle . getSize (). x / 2, 
rectangle . getSize () ,y / 2); 

while (window . isOpen ( ) ) { 
sf:; Event event; 

while (window . pollEvent (event) ) { 

if (event . type == sf :: Event :: Closed) { 

// Close window button clicked, 
window . close ( ) ; 

} 

} 

window . clear ( sf : : Color : : Black) ; 

window . draw ( rectangle) ; // Drawing our shape. 

window . display ( ) ; 

} 

} 

Drawing images in SFML 

In order to draw an image on screen, we need to become familiar with two classes: 
sf : : Texture and sf : : Sprite. A texture is essentially just an image that lives on the 
re on your 

hard drive can be turned into a texture by loading it: 

sf:: Texture texture; 

if ( ! texture . loadFromFile ( "filename .png" ) { 

// Handle an error. 

} 
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The loadFromFile method returns a Boolean value, which serves as a simple way 
of handling loading errors, such as the file not being found. If you have a console 
n 

being printed out in case the texture loading did fail: 

Failed to load image "filename.png". Reason : Unable to open file 



Unless a full path is specified in the loadFromFile method, it will be 
interpreted as relative to the working directory. It's important to note 
that while the working directory is usually the same as the executable's 
when launching it by itself, compiling and running your application 
in an IDE (Microsoft Visual Studio in our case) will often set it to the 


. vcxpro j project file is located if you've provided a relative path. 


It's also possible to load your textures from memory, custom input streams, or 
sf : : image utility classes, which help store and manipulate image data as raw 
pixels, which will be covered more broadly in later chapters. 


What is a sprite? 

A sprite, much like the sf : : shape derivatives we've worked with so far, is 
a sf : : Drawable object, which in this case represents a sf : : Texture and also 
f it as 

a simple rectangle with a texture applied to it: 



sf : : Sprite 
the use 

of textures. Since sf : : Texture isn't a lightweight object, sf : : Sprite comes in for 
ich means 

that as long as a sprite is using the texture it's bound to, the texture has to be alive in 
r we have 

our texture set up, it's really easy to set up the sprite and draw it: 
sf::Sprite sprite (texture) ; 


window . draw ( sprite) ; 
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It's optional to pass the texture by reference to the sprite constructor. The texture it's 
bound to can be changed at any time by using the setTexture method: 

sprite . setTexture (texture) ; 

Since sf : : Sprite, just like sf : : Shape, inherits from sf : : Transformable, we have 
access to the same methods of manipulating and obtaining origin, position, scale, 
and rotation. 

ic application 
that utilizes it: 

void main(int argc, char** argv[]){ 

sf : : RenderWindow window ( sf : : VideoMode (640,480) , 

"Bouncing mushroom. " ) ; 

sf:: Texture mushroomTexture; 

mushroomTexture . loadFromFile ( "Mushroom. png" ) ; 
sf : :Sprite mushroom (mushroomTexture) ; 
sf::Vector2u size = mushroomTexture . getSize () ; 
mushroom. setOrigin (size . x / 2, size.y / 2); 
sf::Vector2f increment ( 0 . 4f , 0.4f); 

while (window . isOpen ( ) ) { 
sf:: Event event; 

while (window . pollEvent (event) ) { 

if (event . type == sf :: Event :: Closed) { 
window . close ( ) ; 

} 

} 

if ( (mushroom . getPosition (). x + (size.x / 2) > 
window . getSize ( ) .x && increment. x >0) | 

(mushroom. getPosition ( ) .x - (size.x / 2) < 0 && 
increment. x < 0)) 

{ 

// Reverse the direction on X axis, 
increment. x = -increment . x; 

} 

if ( (mushroom . getPosition (). y + (size.y / 2) > 
window . getSize ( ) . y && increment. y >0) J 
(mushroom. getPosition ( ) ,y - (size.y / 2) < 0 && 
increment. y < 0)) 

{ 
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// Reverse the direction on Y axis, 
increment. y = - increment . y; 

} 

mushroom. setPosition (mushroom. getPosition ( ) + increment); 

window . clear ( sf Color ( 16 , 16 , 16 , 255 )) ; // Dark gray, 
window . draw (mushroom) ; // Drawing our sprite, 
window. display () ; 

} 

} 

n g in 

oading 

he two i f 

statements after the event handling portion in the main loop are responsible 
on of the 
go towards 
of a shape by 

default is its top-left corner, as shown here: 



Because of this, we must either compensate for the entire width and height of a shape 
make sure its 
r subtract half 
11 within our 

desired space. If it's not, simply invert the sign of the increment float vector on the 
axis that is outside the screen and voila! We have bouncing! 
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For extra credit, feel free to play around with the sf : : sprite's setcolor method, 
it transparent, 

by adjusting the fourth argument of the sf : : Color type, which corresponds to the 
alpha channel: 

mushroom. setColor (sf : :Color (255, 0, 0, 255)); // Red tint. 


Common mistakes 

Oftentimes, new users of SFML attempt to do something like this: 

sf::Sprite CreateSprite ( std :: string l_path) { 
sf:: Texture texture; 
texture . loadFromFile ( l_path) ; 

return sf :: Sprite (texture) ; 

} 

When attempting to draw the returned sprite, a white square pops out where the 
at the 
as long as 

it's being used by a sprite because it stores a pointer to the texture instance. From the 
example above, we can see that it is statically allocated, so when the function returns, 
the texture that got allocated on the stack is now out of scope and gets popped, 
nnot use and 
ust allocate 

memory on the heap instead by making a new call, but that's not the point of this 
ment is 
span of your 

resources. In Chapter 6, Set It in Motion! - Animating and Moving around Your World, 
ing with 

situations like this. 
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Another common mistake is keeping too many texture instances around. A single 
texture can be used by as many sprites as one's heart desires, sf : : Texture is not 
a lightweight object at all, where it's possible to keep tons of sf : : Sprite instances 
xtures is also 
is one of the 

things you really need to remember if you want your application to run fast. That's 
all images 
ping around 

hundreds of texture instances and loading files one by one, we get to simply load a 
d from. That 

will also receive more attention in later chapters. 

Using unsupported image formats or format options is another fairly common 
issue. It's always best to consult the official website for the most up to date 
information on file format support. A short list can be found here: http : //www . 
sfml-dev . org/documentation/ 2 . 2/classsf_l_lImage . php#a9e4f 2aa8e36d0cab 
de5ed5a4ef 80290b 

Finally, the LNK 2 019 errors deserve a mention. It doesn't matter how many times a 
roject to any 

given library. Nothing is perfect in this world, especially not a human being. Your 
IDE output may get flooded by messages that look something like this when trying 
to compile your project: 

error LNK2019: unresolved external symbol. . . 

Do not panic, and please, don't make a new forum post somewhere posting 
hundreds of lines of code. You simply forgot to include all the required additional 
dependencies in the linker input. Revisit the part where we covered setting up the 
. Also, 

remember that you need to include libraries that other libraries are dependent on. 
brary has to 

be included if the graphics module is being used, and so on. Statically linked libraries 
require their dependencies to be linked as well. 
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Summary 

ttle bit 

difficult to grasp at first if you're just starting, but don't be discouraged just yet. 
Applying this knowledge practically is the key to understanding it better. It's 
important that you are competent with everything that has been introduced 
so far before proceeding onto the next chapter. 

If you can truly look throughout this chapter and say with utmost confidence that 
gyour 

first major step towards becoming a successful SFML game developer! Why stop 
there? In the next chapter, we will be covering a better way to structure code for our 
fi we'll 

practically apply everything covered so far by building a major chunk of your first, 
d out! Your 

software isn't going to write itself. 
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Give It Some Structure - 
Building the Game Framework 


ith no 

foundation: it's difficult to maintain, extremely unstable, and will probably cause 
you to abandon it shortly. While the code we worked on in Chapter 1, It's Alive! It's 
Alive! - Setup and First Program, is functional and can be managed on a very small 
scale, expanding it without first building a solid framework would most likely result 
in tons of spaghetti code (not to be confused with ravioli code or lasagna code) being 
e pain of a 

new feature being exponentially more difficult to implement within the source code 
ing we'll be 
focusing on avoiding. 

In this chapter we will cover: 

• Designing a window class, along with a main game class 

• Code restructuring and proper architecture 

• The importance of proper time management in applications 

• Using sf : : Clock and sf : : Time classes 

• Fixed and variable time-steps 
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Graduating to ravioli 

Let's start small. Every game needs to have a window, and as you already know 
from Chapter 1, It's Alive! It's Alive! - Setup and First Program, it needs to be created, 
destroyed, and its events need to be processed. It also needs to be able to clear 
cleared, 
it's in 

full-screen mode, as well as having a method to toggle the latter would be quite 
all of 
e this: 

class Window{ 
public : 

Window ( ) ; 

Window(const std :: strings l_title, const sf : : Vector2u& l_size); 
-Window ( ) ; 

void BeginDraw ( ) ; // Clear the window, 
void EndDrawO; // Display the changes. 

void Update ( ) ; 

bool IsDone ( ) ; 

bool IsFullscreen ( ) ; 

sf::Vector2u GetWindowSize ( ) ; 

void ToggleFullscreen ( ) ; 

void Draw ( sf : : DrawableS l_drawable) ; 
private : 

void Setup(const std::string& l_title, 
const sf : : Vector2u& l_size) ; 
void Destroy ( ) ; 
void Create ( ) ; 

sf : : RenderWindow m_window; 
sf::Vector2u m_windowSize ; 
std::string m_windowTitle ; 
bool m__isDone; 
bool m_isFullscreen; 

} ; 
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thod 

is made private, as well as the destroy and create methods. Think of these as just 
t's a good 
the window 

size or the title that's being displayed above it. Lastly, we keep around two Boolean 
ng full screen. 



The naming convention that's being employed in our window class is 
referred to as the Hungarian notation. Using it is, of course, not required, 

down bugs, and working in larger groups of people. We'll be utilizing 
it throughout this book. More information about it can be found here: 
http : //en . wikipedia . org/wiki/Hungarian_notation 


Implementing the window class 

Now that we have our blueprint, let's begin actually building our window class. 
The entry and exit points seem as good a place as any to start with: 

Window :: Window () { Setup ( "Window" , sf : : Vector2u (640 , 480) ) ; } 


Window: : Window (const std::string& l_title, 
const sf : : Vector2u& l_size) 

{ 

Setup (l_title, l_size) ; 

} 


Window :: -Window () { DestroyO; } 

e helper 
tructor 
ch is not 

necessary, but it's convenient. With that said, let's take a look at the setup method: 

void Window: : Setup (const std::string l_title, 
const sf : : Vector2u& l_size) 

{ 

rrqwindowTitle = l_title; 
m_windowSize = l_size; 
m_isFullscreen = false; 
m_isDone = false; 

Create ( ) ; 

} 


[ 21 ] 


Give It Some Structure - Building the Game Framework 


d keeps track 

of some of the window properties that will be passed to the constructor. Aside from 
that, it calls another method named Create to break up the code even more, which is 
what we'll be implementing next in addition to the Destroy method: 

void Window :: Create () { 

auto style = (m_isFullscreen ? sf :: Style :: Fullscreen 
: sf :: Style :: Default) ; 

m_window . create ( { m_windowSize .x, m_windowSize . y, 32 }, 
m_windowTitle , style) ; 

} 

void Window :: Destroy () { 
m_window. close ( ) ; 

} 

Here, we introduce a new data type that SFML offers: sf : :Uint32. It gets stored 
inside the style local variable, which is automatically deduced to said type by using 
the auto keyword. It's simply an unsigned, fixed size integer type. In this particular 
case, we're using the 32-bit integer, although SFML offers both signed and unsigned 
types of 8, 16, and 32 bits. We use this value to hold the current style for a window 
using a ternary operator and assigning it to either the default or full screen styles 
indow styles 
within SFML: 


Enumerator 

Description 

Mutually 

exclusive 

None 

No border or title bar. The most minimalistic style. 

Yes 

Fullscreen 

Full screen mode. 

Yes 

Titlebar 

Title bar and a fixed border. 

No 

Close 

Title bar and a close button. 

No 

Resize 

Title bar, resizable border and a maximize button. 

No 

Default 

Title bar, resizable border, maximize and close buttons. 

No 


on can be 
window with 

a title bar, resizable border, the maximize button, and a close button by combining 
two styles together using the bitwise or operator in C++: 

auto style = sf :: Style :: Resize | sf :: Style :: Close; 
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ther styles in 
this way. 

Once we have our style, we can simply pass it to the create method of our 
window, in addition to the sf : : VideoMode type that gets constructed, using 
uniform initialization. It's that simple. 

The destroy method of our Window class will simply close the window by invoking 
its closel 

of its attached resources destroyed, but you can still call its create method again to 
re-create the window. Polling events and calling the display method will still work 
if a window is closed. It will just have no effect. 

the events 

of the window in the appropriate update method: 

void Window: : Update () { 
sf : : Event event ; 

while (m_window . pollEvent (event) ) { 

if (event . type == sf :: Event :: Closed) { 
m_isDone = true; 

} else if (event . type == sf :: Event :: KeyPressed && 
event . key . code == sf :: Keyboard :: F5 ) 

{ 

ToggleFullscreen ( ) ; 

} 


} 

It's the same drill as before, we're simply handling events. Instead of closing the 
window right off the bat, however, we simply flip the Boolean flag we keep around 
for checking if the window has been closed or not: m_isDone. Since we're also 
interested in toggling between full screen and normal states of our window, we 
need to keep an eye out for another type of event: sf : : Event : : KeyPressed. This 
ludes 

information about that key stored in the event . key struct. For now, we're only 
against 

the sf : : Keyboard enumeration table. Upon receiving an event of an F5 key being 
pressed, we call the ToggleFullscreen method, which is fairly simple to implement 
now that we have broken up the code into manageable sections: 

void Window :: ToggleFullscreen () { 

m__isFullscreen = !m_isFullscreen; 

Destroy ( ) ; 

Create ( ) ; 

} 
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As you can see, the only thing we do here is invert the value of our Boolean class 
member, m_isFullscreen, that keeps track of the window state. Afterwards, we 
hanges. 

Let's take a look at the drawing methods: 

void Window :: BeginDraw () { m_window . clear ( sf :: Color :: Black) ; } 
void Window :: EndDraw () { m_window . display () ; } 

Nothing new gets introduced here. We're simply wrapping the functionality of 
clearing and displaying in BeginDraw and EndDraw methods. All that's left now 
are the simple helper methods: 

bool Window :: IsDone () { return m_isDone; } 

bool Window :: IsFullscreen () { return m_isFullscreen; } 

sf::Vector2u Window :: GetWindowSize () { return m_windowSize ; } 

void Window: :Draw(sf : :Drawable&l_drawable) { 
m_window . draw (l_drawable) ; 

} 

These basic methods provide the means for retrieving information about the window 
r now, our 

window class is more than sufficient. 

Building the game class 

ow class, 

but that's not the only chunk of code in need of refactoring. In Chapter 1, It's Alive! 

It's Alive! - Setup and First Program, we've discussed the main game loop and its 
r, and 

finally, rendering everything on screen. Cramming all of that functionality into the 
we want 
ow this kind 
of behavior: 

# inc lude " Game . h " 

void main(int argc, void** argv[]){ 

// Program entry point. 

Game game; // Creating our game object, 
while ( ! game . GetWindow ( ) - >IsDone ( ) ) { 

/ / Game loop . 
game . Handlelnput ( ) ; 
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game .Update () ; 
game . Render ( ) ; 

} 

} 

The code above represents the entire content of our main . cpp file and perfectly 
o beyond 
he window is 

closed. Just for the sake of clarity, let's take a look at a simplified version of the game 
class header: 

class Game{ 
public : 

Game ( ) ; 

-Game ( ) ; 

void Handlelnput () ; 
void Update ( ) ; 
void Render ( ) ; 

Window* GetWindowO; 

private : 

void MoveMushroom ( ) ; 

Window m_window; 


In- 


differently, 

but for our current needs this will more than suffice. 

Putting our code to work 

We're now ready to re-implement the bouncing mushroom demo from Chapter 1, 
It's Alive! It's Alive! - Setup and First Program. Given how simple it is, we'll walk 
o our new 

structure. Let's begin by setting up our window and graphics we'll be using: 

Game :: Game () : m_window ( "Chapter 2", sf : : Vector2u (800 , 600) ) { 

// Setting up class members. 

m_mushroomTexture . loadFromFile ( "Mushroom. png" ) ; 
m_mushroom. setTexture (m_mushroomTexture) ; 
m__increment = sf : :Vector2i (4 , 4) ; 

} 
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ty 

for now: 

Game : : -Game ( ) { } 

method alone 
sprite 

each frame: 

void Game :: Update () { 

m_window . Update () ; // Update window events. 

MoveMushroom ( ) ; 

} 

void Game :: MoveMushroom () { 

sf::Vector2u l_windSize = m__window . GetWindowSize ( ) ; 
sf::Vector2u l_textSize = mmushroomTexture . getSize ( ) ; 

if ( (m_mushroom. getPosition ( ) ,x > 

l_windSize.x - l_textSize . x&&m_increment . x> 0) j 
(m_mushroom . getPosition (). x < 0 &&m_increment . x< 0) ) { 
m_increment.x = -m_increment.x; 

} 


if ( (m_mushroom. getPosition ( ) ,y > 

l_windSize.y - l_textSize . y&&m_increment . y> 0) j j 
(mmushroom. getPosition () ,y < 0 &&m_increment . y< 0) ) { 
mincrement . y = -m_increment . y ; 

} 


m_mushroom. setPosition ( 

m_mushroom . getPosition (). x + m_increment . x, 
m_mushroom . getPosition (). y + m_increment . y) ; 

} 

Literally the first thing you'll probably notice is the update method call of our 
window class. We've already covered the importance of event processing in SFML, 
but it's still worthy to note that one more time. The rest of the code is pretty much 
pdating 

the position of the mushroom sprite. We used two local variables to hold the window 
and texture sizes in order to increase readability, but that's about it. Time to draw 
our sprite to the screen: 

void Game :: Render () { 

m_window . BeginDraw ( ) ; // Clear. 
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m_window . Draw (m_mushroom) ; 
m_window . EndDraw ( ) ; // Display. 


11 the work, 

and all we have to do is call the Draw method and pass in our sf : : Drawable right in 
hanges. 

Putting everything together and running it should produce the exact same bouncing 
mushroom we had back in Chapter 1, It's Alive! It's Alive! - Setup and First Program. 
how 
t game 

development. 

Hardware and execution time 

Let's travel back in time to May 5, 1992. Apogee Software begins publishing the now 
known cult classic Wolfenstein 3D developed by id Software: 



SCORE 

100 


I HEALTH I AMMO H 

U. I00Z 14 


The man with the vision, John Carmack, took massive strides forward and not only 
popularized, but also revolutionized the first person shooter genre on the PC. Its 
massive success cannot be overstated, as even now it's difficult to accurately predict 
hat 

is game 

again. Ever since its original release for the DOS operating system on the PC, it has 
11 possible 
onment our 
ast is no 

longer compatible, hence the need for emulation. 
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An emulator is either software, hardware, or the combination of both, 
o 

as a guest, on a primary system, referred to as the host. 


e of a 

system that would be compatible with a title you're attempting to play, but also the 
n the 
d it was 

running on a 4. 77 MHz system, which allowed the developers to save some clock 
cycles for the sake of efficiency by not writing internal timing loops. A game like 
Wolfenstein 3D consumed all of the processing power, which was a fine strategy for 
the time, until more powerful and faster processors came about. Today, the puny 
4.77 MHz speed is dwarfed by comparison, even when looking at all of the cheapest 
consumer-grade processors, so proper emulation of a specific system also requires 
the reduction of CPU clock cycles, otherwise these games will run too fast, which 
doesn't 

throttle the speed enough. 

While this is the most extreme example, speed management is an important 
component of any piece of software today that has to run at a constant speed. 
Different choices of hardware and architecture aside, your software might run faster 
or slower simply based on how busy your system is at the time or the different tasks 
your code needs to accomplish every iteration before the image is rendered. Consider 
the following illustration: 


Slower hardware 

Faster hardware 


*** 

41 * 

41 * 

*** 


41 * 

>* 


41 * 
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ver a 1 second 

interval. The code is exactly the same in both cases. The only difference is the number 
edictably, the 
yield fewer 

iterations, resulting in the sprite being moved fewer times during our 1 second time 

is important 

gnated 

specification guidelines. This is where SFML time management comes in. 

Controlling the frame-rate 

SFML provides a means of setting a frame-rate cap for your applications. It's a 
method in the sf : :RenderWindow class, appropriately called setFramerateLimit: 

m_window. setFramerateLimit (60) ; // 60 FPS cap. 

Although this feature is not absolutely reliable, it ensures that the application's 

sion, as 

rame-rate 

reduces the overall CPU consumption of the program as well, since it doesn't need to 
update and re-draw the same scene as many times anymore. It does, however, raise a 
d value, the 
r problem. Let's 

take a look at something more practical. Enter sf : : clock! 

Using the SFML clock 

The sf : : clock class is very simple and lightweight, so it has only two methods: 
getElapsedTime ( ) and restart ( ) . Its sole purpose is to measure elapsed time since 
n the most precise 
e using 

the getElapsedTime method, it returns a type sf : : Time. The main reasoning behind 
that is an additional layer of abstraction to provide flexibility and avoid imposing 
any fixed data types. The sf : : Time class is also lightweight and provides three 
useful methods for conversion of elapsed time to seconds which returns a floating 
point value, milliseconds, which returns a 32-bit integer value and microseconds, 
which returns a 64-bit integer value, as represented here: 

Sf : :Clock clock; 


sf::Time time = clock . getElapsedTime (); 


[29] 


www.allitebooks.com 


Give It Some Structure - Building the Game Framework 


float seconds = time . asSeconds ( ) ; 

sf::Int32 milliseconds = time . asMilliseconds ( ) ; 

sf::Int64 microseconds = time . asMicroseconds ( ) ; 

time = clock . restart () ; 

As you can see, the restart method also returns an sf : : Time value. This is 
provided in order to avoid calling getElapsedTime right before calling the restart 
rwise 
dealing 
couldn't 

account for their speed. We moved our sprite across the screen using this line 
of code: 

m_mushroom . setPosition ( 

m_mushroom . getPosition ( ) . x + m_increment .x, 
m_mushroom . getPosition ( ) . y + m_increment . y) ; 

The m increment vector here is used with an assumption that the time between 
iterations is constant, but that's obviously not true. Recall the magic triangle for 
the speed, time, and distance formula: 



Finding the distance a sprite should travel in between updates can be done by first 
defining a set speed at which it moves. The time value here is simply how long it 
takes for an entire cycle of the program to finish. In order to accurately measure that, 
we're going to be adjusting the Game class to utilize the sf : : Clock: 

class Game{ 
public : 


sf::Time GetElapsed ( ) ; 
void RestartClock ( ) ; 
private : 
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sf::Clock m_clock; 
sf::Time m_elapsed; 


} ; 

The two new public methods we've added can be implemented like so: 

sf::Time Game : : GetElapsed ( ) { return m_elapsed; } 

void Game : : RestartClock ( ) { m_elapsed = m_clock . restart () ; } 

Once that is done, it's important to actually utilize this functionality and restart 
me loop 

by simply calling the RestartClock method after all the work is done: 

while ( ! game . GetWindow ( ) - >IsDone ( ) ) { 

/ / Game loop . 
game . Handlelnput ( ) ; 
game .Update () ; 
game . Render ( ) ; 

game . RestartClock () ; // Restarting our clock. 

} 

The last line in the loop will make sure that the m_e lapsed member of the game class 
n, so let's use 

that time and determine how far our sprite should have moved: 

float f Elapsed = m_elapsed . asSeconds ( ) ; 

m_mushroom . setPosition ( 

m_mushroom . getPosition ( ) . x + (m_increment . x * fElapsed) , 
m_mushroom . getPosition ( ) . y + (m_increment . y * fElapsed)); 

We're now using m_increment as a variable of speed, not distance. By looking at our 
previous code in the constructor, we've set both x and y values of the m increment 
vector to a value of 4 . Since we're expressing our elapsed time as seconds, this is 
essentially like saying that the sprite needs to move 4 pixels a second. That's really 
slow, so let's change it to something a little bit more stimulating: 

Game : ; Game ( ) { 

m_increment = sf : :Vector2i (400 , 400) ; // 400px a second. 

} 
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Upon compiling and running the project, you should see our sprite happily bouncing 
across the screen. It will now be moved the same distance on every single machine 
it's executed on, no matter how choppy the frame-rate is. For extra points, try it out 
yourself by artificially slowing down the game loop with the sf : : sleep function 
that SFML provides, like so: 

while ( ! game . GetWindow ( ) - >IsDone ( ) ) { 

/ / Game loop . 
game . Handlelnput ( ) ; 
game. Update () ; 
game . Render ( ) ; 

sf :: sleep (sf :: seconds (0 . 2) ) ; // Sleep for 0.2 seconds. 

game . RestartClock ( ) ; 

} 

notice that it 

moves the sprite across exactly the same distance, no matter how long each iteration 
takes to finish. 

Fixed time-step 

eally 

apply correctly. Let's say we only want to call certain methods at a fixed rate of 60 
times per second. It could be a physics system that requires updating only a certain 
the case is, 

when an update rate is really important, a fixed time-step is your friend. Unlike the 
variable time-step, where the next update and draw happens as soon as the previous 
one is done, the fixed time-step approach will ensure that certain game logic is 
only happening at a provided rate. It's fairly simple to implement a fixed time-step, 
lue of the 

previous iteration, we add to it like so: 

void Game :: RestartClock () { 

m^elapsed += m_clock . restart () ; 

} 
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1 update 

throughout a 1 second interval is illustrated here: 


Chapter 2 


l.Of 

FrameTime = — — 

updates/s 


Let's say we want our game to update 60 times a second. To find the frame time, 
we would divide 1 by 60 and check if the elapsed time has exceeded that value, 
as shown here: 

float frametime = l.Of / 60.0f; 

if (m_elapsed . asSeconds ( ) >= frametime) { 

//Do something 60 times a second. 

m_elapsed -= sf :: seconds (frametime) ; // Subtracting. 

} 

ep the 

simulation running at a constant speed. Depending on your application, you might 
want to put it to sleep in between updates in order to relieve the CPU. Aside from 
that detail, these are the bare bones of the fixed time-step. This is the exact technique 
that will be used in the game that we will finish building in the next chapter. 


Common mistakes 

g places 

and restart them at the wrong times. Things like that can result in "funky" behavior 
at best. 



Keep in mind that every line of code that isn't empty or commented out 
takes time to execute. Depending on how a function that is being called, 
ht 

range from miniscule to infinite. 
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alculations, 

somehow 

exclude these calls from the span of your time measurement. Always make sure 
that restarting the clock and grabbing the elapsed time is the last thing you're 
doing before the main game loop ends. 

ider 

this example: 

void Game : : SomeMethod ( ) { 
sf : :Clock clock; 


sf::Time time = clock . getElapsedTime () ; 

} 

her than the 

time since the sf : : clock object was initiated, this code will produce faulty results, 
ve within 
me class was 

declared as the class member. Since the clock is created on the stack, as soon as the 
method above concludes, the clock will be destroyed again. 

Keeping an elapsed time in a float data type, or any other data type that isn't 
sf : : Time for that matter, is also something that's generally frowned upon. 
Something like this would not be a great example of proper use of SFML: 

class Game{ 


private : 


float m_elapsed; 


Although it works, this isn't exactly type-safe. It also requires more type conversions 
s each time 

the clock gets restarted. One more nail to seal the coffin would be code readability. 
SFML provides its own time class for a reason and convenience, so unless there's a 
good reason not to use it, do avoid any other data types. 
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One last thing that deserves a mention since we're talking about time is the console 

output in C++. While it's just fine to print something out every now and then, even 

ation 

execute at 

n every 

ation 

speed horribly. 

Summary 

Congratulations on finishing the second chapter of this book! As mentioned 
his 

red here. 

Smooth and consistent results on different platforms and under different conditions 
t another 

layer of lasagna, if you will. Upon successful completion of this chapter, you are left 
yet again with sufficient knowledge to produce applications that can utilize both 
fitically and 

independently of the underlying architecture. 

Finally, we will leave you with a piece of good advice. The first few chapters are 
at's an 

guide instead 
't simply 
1 

so go ahead 
rs, run it or 
order to one 
s dirty, as 

we will actually begin implementing our first game project for this book in the next 
chapter. See you there! 
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Get Your Hands Dirty - What 

You Need to Know 


es, the 

amount of time spent on writing a specific chunk of code, implementing a certain 
set of features, or revising an old code that you or someone else had written shows 
ay at some 

point see a game developer's face light up in instant joy when a flashier segment of 

ife and begin 

elopers do 

timulating 

results possible. 

fun, 

flashy parts! 

In this chapter, we will cover: 

• The game of choice for our first project and its history 

• Building the game we've chosen 

• Common game programming elements 

• Additional SFML elements needed to complete our project 

• Building helper elements for all our game projects 

• Effective debugging and common problem solving in games 
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Introducing snake 

If right now you're imagining building a game with Solid Snake wearing his 
trademark bandana, we're not quite there yet, although the eagerness to do so is 
ou're 

right on point: 



First published by Gremlin in 1976 under the name "Blockade", the snake concept is 
written 

for this type of mechanic, such as Surround by Atari in 1978 and Worm by Peter 
Trefonasn it, 

even including the early monochrome Nokia phones, such as the 3310 and 6110. The 
main 

idea and the rules remained the same ever since its humble beginnings: 

• The snake can move in four total directions: up, down, left, and right 

• Eating an apple makes the snake grow in length 

• You cannot touch the walls or your own body, otherwise the game is over 

uch as 
the speed 

at which the snake moves, the size of the playing field, obstacles, and so on. 
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Game design decisions 

ng homage to 
on a grid, 
as illustrated next: 






i 



n the snake 
ic rate. 

This can be achieved by utilizing a fixed time-step, which we covered back in 
Chapter 2, Give It Some Structure - Building the Game Framework. 

e of a 

grid-based movement would be in the range of [l;Width-l] and [l;Height-l] . If the 
snake head isn't within that range, it's safe to say that the player has crashed into a 
wall. All the grid segments here are 16px by 16px big; however, that can be adjusted 
at any time. 

nt of 
of lives 

left. This adds a little variety to the game without being too unbalanced. 

Lastly, you've probably already picked up on the fact that we're using very simplistic 
mainly to 

keep things simple for now, as well as to add the charm of a classic to the mix. It 

not worry 

about that just yet. 
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Implementing the snake structure 

Let's now create the two files we'll be working with: Snake . h and Snake . cpp. Prior 
to actually developing the snake class, a definition of some data types and structures 
is in order. We can begin by actually defining the structure that our apple eating 
serpent will be made out of, right in the snake header file: 

struct SnakeSegment { 

SnakeSegment (int x, int y) : position (x, y) { } 
sf::Vector2i position; 

} ; 


her, which is 

an integer vector representing the position of the segment on the grid. The constructor 
here is utilized to set the position of the segment through an initializer list. 

Before moving past this point, make sure you're competent with the 
Standard Template Library and the data containers it provides. We 
will specifically be using std : : vector for our needs. 

We now have the segment type defined, so let's get started on actually storing the 
snake somewhere. For beginner purposes, std: : vector will do nicely! Before going 
too far with that, here's a neat little trick for curing our code of "long-line-itus": 

using SnakeContainer = std : : vector<SnakeSegment> ; 

As you should already know from your C/C++ background, using is a neat little 
keyword that allows the user to define aliases for the known data types. By using 
our clean new definitions together with the auto keyword, we're preventing a 
scenario like the following from ever happening: 

std :: vector<SnakeSegment> :: iterator somelterator = ... 

It's a simple matter of convenience and is completely optional to use, however, 
we will be equipping this useful tool all the way through this book. 

One last type we need to define before beginning to really work on the snake class, 
is the direction enumeration: 

enum class Direction! None, Up, Down, Left, Right }; 

move in. 
st set the 

direction to NONE. 



[ 40 ] 


Chapter 3 


The snake class 

case, the 

snake needs to have a direction to move towards. It also needs to have lives, keep 
st or not. Lastly, 

we're going to store a rectangle shape that will represent every segment of the snake. 
When all these are addressed, the header of the snake class would look something 
like the following: 

class Snake { 
public : 

Snake(int l_blockSize) ; 

-Snake ( ) ; 

// Helper methods. 

void SetDirection (Direction l_dir) ; 

Direction GetDirection ( ) ; 
int GetSpeedO; 
sf::Vector2i GetPosition ( ) ; 
int GetLivesO; 
int GetScoreO; 
void IncreaseScore () ; 
bool HasLostO; 

void Lose () ; // Handle losing here, 
void ToggleLost ( ) ; 

void Extend () ; // Grow the snake. 

void ResetO; // Reset to starting position. 

void Moved ; // Movement method, 
void Tick(); // Update method. 

void Cut (int l_segments) ; // Method for cutting snake, 
void Render ( sf :: RenderWindow& l_window) ; 
private : 

void CheckCollision ( ) ; // Checking for collisions. 

SnakeContainer m_snakeBody; // Segment vector, 
int m_size; // Size of the graphics. 

Direction m_dir; // Current direction. 

int m_speed; // Speed of the snake. 

int m_lives; // Lives. 

int m_score; // Score. 

bool m_lost; // Losing state. 

sf : : RectangleShape m_bodyRect; // Shape used in rendering. 

} ; 
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his doesn't 

look that helpful just yet, but it's about to be, really soon. 

As you can see, our class has a few methods defined that are designed to split up the 
functionality, such as Lose ( ) , Extend ( ) , Reset ( ) , and CheckCollision ( ) . This will 
implementing 
these methods: 

Snake :: Snake ( int l_blockSize) { 
m_size = l_blockSize; 

m_bodyRect . setSize (sf : : Vector2f (m_size - 1, m_size - 1) ) ; 

Reset ( ) ; 

} 

Snake : : -Snake ( ) { } 

is the 

size of our graphics. This value gets stored for later use and the member of type 
sf : : RectangleShape gets its size adjusted based on it. The subtraction of one pixel 
s appear 

visually slightly separated, as illustrated here: 


m_size 

m_size - 1 




The constructor also calls the Reset ( ) method on the last line. A comment in the 
header fi 

starting position. Let's make that happen: 

void Snake :: Reset () { 

m_snakeBody . clear ( ) ; 

m_snakeBody . push_back ( SnakeSegment (5,7)); 
m_snakeBody . push_back ( SnakeSegment (5,6)); 
m_snakeBody . push_back ( SnakeSegment (5,5)) ; 

SetDirection (Direction : :None) ; // Start off still. 

m_speed = 15; 

m_lives = 3; 

m_score = 0 ; 

m_lost = false; 

} 
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t will clear the 
ents will 

get added. Because of our implementation, the first element in the vector is always 
for now, 

just to keep it simple. 

Now we have a three-piece snake. The first thing we do now is set its direction to 
None 

nd the starting 

score. These can be adjusted to your liking later. We also set the m lost flag to false 
in order to signify a new round taking place. 

Before moving on to more difficult to implement methods, let's quickly cover all the 
helper ones: 

void Snake :: SetDirection (Direction l_dir) { m_dir = l_dir; } 

Direction Snake :: GetDirection () { return m_dir; } 
int Snake :: GetSpeed () { return m_speed; } 

sf : :Vector2i Snake: : GetPosition ( ) { 
return (! m_snakeBody . empty ( ) ? 

m_snakeBody. front () .position : sf : : Vector2i ( 1 , 1 ) ) ; 

} 


int Snake :: GetLives () { return m_lives; } 
int Snake :: GetScore () { return m_score; } 

void Snake :: IncreaseScore () { m_score += 10; } 
bool Snake :: HasLost () { return m_lost; } 
void Snake :: Lose () { mlost = true; } 
void Snake :: ToggleLost () { m_lost = !m_lost; } 

These methods are fairly simple. Having descriptive names helps a lot. Let's take a 
look at the Extend method now: 

void Snake :: Extend () { 

if (m_snakeBody. empty () ) { return; } 

SnakeSegment& tail_head = 

m_snakeBody [m_snakeBody . size ( ) - 1] ; 

if (m_snakeBody . size ( ) > 1) { 

SnakeSegment& tail_bone = 

m_snakeBody [m_snakeBody . size ( ) - 2] ; 
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if (tail_head . position . x == tail_bone . position . x) { 
if (tail_head. position. y > tail_bone . position . y) { 
m_snakeBody .push_back (SnakeSegment ( 

tail_head .position . x, tail_head . position . y + 1) ) ; 

} else { 

m_snakeBody .push_back (SnakeSegment ( 

tail_head .position . x, tail_head . position . y - 1) ) ; 

} 

} else if (tail_head. position. y == tail_bone .position . y) { 
if (tail_head . position . x > tail_bone . position . x) { 
m_snakeBody .push_back (SnakeSegment ( 

tail_head. position. x + 1, tail_head . position . y) ) ; 

} else { 

m_snakeBody .push_back (SnakeSegment ( 

tail_head .position . x - 1, tail_head . position . y) ) ; 

} 

} 

} else { 

if (m_dir == Direction: :Up) { 

m_snakeBody ,push_back (SnakeSegment ( 

tail_head . position . x, tail_head .position . y + 1) ) ; 

} else if (m_dir == Direction :: Down) { 
m_snakeBody ,push_back (SnakeSegment ( 

tail_head. position. x, tail_head .position . y - 1) ) ; 

} else if (m_dir == Direction :: Left ) { 
m_snakeBody ,push_back (SnakeSegment ( 

tail_head . position . x + 1, tail_head .position . y) ) ; 

} else if (m_dir == Direction :: Right ) { 
m_snakeBody ,push_back (SnakeSegment ( 

tail_head. position. x - 1, tail_head .position . y) ) ; 

} 

} 

} 

r snake 

when it touches an apple. The first thing we did was create a reference to the last 
element in the segment vector, called tail_head. We have a fairly large if-else 
statementment, 
icated code. 
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The std : : vector container overloads the bracket operator in order 
to support random access via a numeric index. It being similar to an 

of size () - 1. The random access speed is also constant, regardless 
of the number of elements in this container, which is what makes the 
std : : vector a good choice for this project. 


Essentially, it comes down to two cases: either the snake is longer than one segment 
rence, called 

tail_bone, which points to the next to last element. This is needed in order to 
it, and 

the way we check for that is by comparing the position.x and pos it ion. y values 
of the tail_head and tail_bone segments. If the x values are the same, it's safe 
to say that the difference between the two pieces is on the y axis and vice versa. 
Consider the following illustration, where the orange rectangle is tail bone and 
the red rectangle is tail_head: 
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Let's take the example that's facing left and analyze it: tail_bone and tail_head 
have the same y coordinate, and the x coordinate of tail_head is greater than that of 
tail_bone, so the next segment will be added at the same coordinates as tail_head, 
except the x value will be increased by one. Because the SnakeSegment constructor is 
conveniently overloaded to accept coordinates, it's easy to perform this simple math 
at the same time as pushing the segment onto the back of our vector. 

ck the 

direction of our snake and perform the same math as we did before, except that this 
ion applies to 
le is the piece 

that's about to be added. If it's facing left, we increase the x coordinate by one while 
leaving j/ake 
e. 

Of course, none of this would matter if our snake didn't move. That's exactly what is 
being handled in the update method, which in our case of a fixed time-step is referred 
to as a "tick": 


void Snake :: Tick () { 

if (m_snakeBody . empty ()) { return; } 
if (m_dir == Direction : :None ) { return; } 

Move ( ) ; 

CheckCollision ( ) ; 

} 

The fied 

or not, based on its size and direction. As mentioned earlier, the Direction: :None 
value is used specifically for the purpose of keeping it still. The snake movement is 
contained entirely within the Move method: 

void Snake :: Move () { 

for (int i = m__snakeBody . size ( ) - 1; i > 0; --i){ 

m_snakeBody [i] .position = m_snakeBody [i - 1] .position; 

} 

if (m_dir == Direction :: Left ) { 

- -m_snakeBody [0] . position. x; 

} else if (m dir == Direction :: Right ) { 

++m_snakeBody [0] . position. x; 

} else if (m__dir == Direction :: Up) { 

- -m_snakeBody [0] . position. y; 

} else if (m dir == Direction :: Down) { 

++m_snakeBody [0] . position. y; 


} 
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We start by iterating over the vector backwards. This is done in order to achieve an 
inchwormtor in 

reverse as well, however, this serves the purpose of simplicity and makes it easier to 
understand how the game works. We're also utilizing the random access operator again 
to use numeric indices instead of the vector iterators for the same reasons. Consider 
the following illustration: 


Beginning state 


Iteration 1 


mm 


Iteration 2 


H 


Iteration 3 


3 2 1 


We have a set of segments in their positions before we call the tick method, which 
can be referred to as the "beginning state". As we begin iterating over our vector 
backwards, we start with the segment #3. In our for loop, we check if the index 
is equal to 0 
e the same as the 
n between the 
oth of them. 

In reality, segment #3 is sitting right on top of segment #2. 
we move 

on to its head. At this point, we simply move it across one space in the axis that 
corresponds to its facing direction. The same idea applies here as it did in the 
illustration before this one, but the sign is reversed. Since in our example, the snake 
is facing right, it gets moved to the coordinates (x+l;y). Once that is done, we have 
successfully moved our snake by one space. 

One last thing our tick does is call the CheckCollision ( ) method. Let's take a look 
at its implementation: 

void Snake :: CheckCollision () { 

if (m_snakeBody . size ( ) < 5) { return; } 

SnakeSegment& head = m_snakeBody . front () ; 
for (auto itr = m_snakeBody . begin ( ) + 1; 
itr != m_snakeBody . end ( ) ; ++itr) 
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{ 

if ( itr- >position == head . position) { 

int segments = m_snakeBody . end ( ) - itr; 

Cut (segments) ; 

break; 

} 


} 

First, there's no need to check for a collision unless we have over four segments, 
t waste 

resources is an important part of game development. If we have over four segments 
se of collision, 

that's the first part that would hit another segment. There is no need to check for a 

the head of the 

tself. 

The basic way we check for a collision in this grid-based game is essentially by 
comparing the position of the head to the position of the current segment represented 
by our iterator. If both positions are the same, the head is intersecting with the body. 
The way we resolve this was briefly covered in the Game design decisions section of 
this chapter. The snake has to be cut at the point of collision until the player runs out 
of lives. We do this by first obtaining an integer value of the segment count between 
the end and the segment being hit. STL is fairly flexible with its iterators, and since 
the memory in the case of using a vector is all laid out contiguously, we can simply 
subtract our current iterator from the last element in the vector to obtain this value. 
This is done in order to know how many elements to remove from the back of the 
snake up until the point of intersection. We then invoke the method that is responsible 
for cutting the snake. Also, since there can only be one collision at a time, we break out 
of the for loop to not waste any more clock cycles. 

Let's take a look at the Cut method: 

void Snake Cut ( int l_segments) { 

for (int i = 0; i < l_segments; ++i) { 
m_snakeBody . pop_back ( ) ; 

} 

- -m_lives ; 

if (!m_lives){ Lose ( ) ; return; } 

} 

on the 

l_segments value and popping the elements from the back of the vector. This 
effectively slices through the snake. 
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The rest of the code simply decreases the amount of lives left, checks if it's at zero, 
and calls the Lose ( ) method if there are no more lives. 

that is 

rendering our square serpent to the screen: 

void Snake :: Render ( sf :: RenderWindowk l_window) { 
if (m_snakeBody . empty ()) { return; } 

auto head = m_snakeBody . begin () ; 
m_bodyRect . setFillColor ( sf ; : Color : : Yellow) ; 
m_bodyRect . setPosition (head- >position . x * m_size, 
head- >position . y * m_size) ; 
l_window . draw (m_bodyRect ) ; 

m_bodyRect . setFillColor ( sf ; : Color : : Green) ; 
for (auto itr = m_snakeBody . begin ( ) + 1; 
itr != m snakeBody . end ( ) ; ++itr) 

{ 

m_bodyRect . setPosition ( itr- >position . x * m_size, 
itr- >position . y * m_size); 
l_window . draw (m_bodyRect ) ; 


} 

a need to 
in order to 

avoid unnecessary checks. We set the position of our sf : : RectangleShape that 
y the m_size 

e rectangle is 

the last step of implementing the snake class in its entirety! 


The World class 

oesn't make 
unch on to 

increase the score by introducing the World class. 

While it's possible to just make separate objects for everything we talk about in 
o be nicely 
ouble. 
es, as well 

as maintaining the apple the player will be trying to grab. 
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Let's take a look at the class header: 

class World{ 
public : 

World (sf : :Vector2u l_windSize) ; 

-World ( ) ; 

int GetBlockSize ( ) ; 

void RespawnApple () ; 

void Update (Snake& l_player) ; 
void Render ( sf :: RenderWindow& l_window) ; 
private : 

sf::Vector2u m_windowSize ; 
sf::Vector2i m_item; 
int m_blockSize; 

sf : : CircleShape m_appleShape ; 
sf : : RectangleShape m_bounds [4] ; 

} ; 

As you can see from the preceding code, this class also keeps track of how big the 
les for the 
to keep 

track of the apple's coordinates, which is named m_item. Let's start implementing 
the constructor: 

World: : World (sf : :Vector2u l_windSize) { 
m_blockSize = 16; 

m_windowSize = l_windSize; 

RespawnApple ( ) ; 

m_appleShape . setFillColor ( sf : : Color: :Red) ; 
m_appleShape . setRadius (m_blockSize / 2); 

for(int i = 0; i < 4; ++i){ 

m_bounds [i] . setFillColor (sf : : Color (150 ,0,0)); 
if (! ( (i + 1) % 2) ) { 

m_bounds [i] . setSize (sf : :Vector2f (m_windowSize .x, 
m_blockSize) ) ; 

} else { 

m_bounds [i] ,setSize(sf: : Vector2f (m_blockSize , 
m_windowSize . y) ) ; 

} 
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if (i < 2) { 

m_bounds[i] . setPosition ( 0 , 0 ) ; 

} else { 

m_bounds[i] . setOrigin (m_bounds [i] .getSizeO); 
m_bounds [i] . setPosition (sf : :Vector2f (m_windowSize) ) ; 

} 

} 

} 


World : : -World ( ) { } 

Up until the complex looking for loops, we simply initialize some member values 
from the local constructor variables, set the color and radius of the apple circle, and 
call the RespawnApple ( ) method in order to place it somewhere on the grid. 

The first f orreen 
color for the 

rectangle fill and proceeds with checking the index value. First, we determine if 
xpression: 

if ( ! ( ( i + l) % 2 )){... . This is done in order to know how big each wall has to 
be on a specific axis. Because it has to be as large as one of the screen dimensions, we 
en, which is 

represented by the m_blocksize value. 

The last ifh 
,0). Since the 
ft corner, we 
or higher, we 

set the origin to the size of the rectangle, which effectively makes it the bottom right 
as the size of 

the screen, which puts the shape all the way down to the bottom right corner. You 
h makes the 
ee the use for 
in handy, 

so why not start now? 

spawning 
the apple: 

void World :: RespawnApple () { 

int maxX = (m_windowSize . x / m_blockSize) - 2; 
int maxY = (m__windowSize . y / m_blockSize) - 2; 
m_item = sf : : Vector2i ( 

rand ( ) % maxX + 1 , rand ( ) % maxY + 1 ) ; 
m_appleShape . setPosition ( 
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m_item.x * m_blockSize, 
m_item.y * m_blockSize) ; 


The fican 

be spawned. We do so by defining two values: maxX and maxY. These are set to the 
es in the 
he grid indices 

begin with 0, not 1, and because we don't want to spawn the apple within the right 
or bottom wall s . 

The next step is to actually generate the random values for the apple coordinates. 
We use our pre-calculated values here and set the lowest possible random value to l, 
because we don't want anything spawning in the top wall or the left wall. Since the 
coordinates of the apple are now available, we can set the m_appleshape graphic's 
position in pixel coordinates by multiplying the grid coordinates by the size of all 
our graphics. 

update 

method: 

void World :: Update (Snake& l_player) { 

if ( l_player . GetPosition ( ) == m_item) { 
l_player . Extend ( ) ; 
l_player . IncreaseScore ( ) ; 

RespawnApple ( ) ; 

} 


int gridSize_x = m_windowSize . x / m_blockSize; 
int gridSize_y = m_windowSize . y / m_blockSize; 


} 


if ( l_player . GetPosition ( ) .x <= 0 | j 
l_player . GetPosition ( ) .y <= 0 | 
l_player . GetPosition (). x >= gridSize_x 
l_player . GetPosition (). y >= gridSize_y 


l_player . Lose ( ) ; 


} 


1 I i 
1 ) 


e. If it is, we have 
pie gets re- 
nates are 

11 the Lose ( ) 

method to illustrate the collision with the wall and give the player a "game over". 
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the game, as 
screen: 

void World :: Render ( sf :: RenderWindow& l_window) { 
for(int i = 0; i < 4; ++i) { 

l_window . draw (m_bounds [i] ) ; 

} 

l_window . draw (m_appleShape) ; 

} 


tive 

method. 

One more thing to point out is that the other classes might need to know how big 
ethod for 

obtaining that value: 

int World :: GetBlockSize () { return m_blockSize; } 

This concludes the World class. 

Time to integrate 

Much like how a hammer is useless without someone using it, so are our two classes 
without being properly adopted by the Game class. Since we didn't write all that code 
just to practise typing, let's work on putting all the pieces together. First, we need 
to actually add two new members to the Game class, and you might already have 
guessed what they are: 

class Game{ 
private : 


} ; 


World m_world; 
Snake m_snake ; 


rs that take 

arguments, it's the time for initializer list: 

Game :: Game () : m_window (" Snake " , sf : : Vector2u (800 , 600)), 

m_snake (m_world . GetBlockSize ( ) ) , m_world ( sf : : Vector2u (800,600) ) 

{ 

} 
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Next, we need to process some input. As you may recall from the previous chapters, 
utilizing events for live input is really delayed and should never be used for anything 
else but checking for key presses that aren't time sensitive. Luckily, SFML provides 
means of obtaining the real-time state of the keyboard through the sf : : Keyboard 
class. It only contains the static functions and is never meant to be initialized. One of 
those functions is exactly what we need here: isKeyPressed (sf : : Keyboard : : Key) . 
The sole argument that it takes is the actual key you want to check the state of, which 
can be obtained through the use of the sf : : Keyboard : : Key enumeration, as follows: 

if ( sf : : Keyboard : : isKeyPressed ( sf : : Keyboard : : Up) 

&& m_snake . GetDirection ( ) != Direction: : Down) 

{ 

m_snake . SetDirection (Direction : :Up) ; 

} else if (sf :: Keyboard :: isKeyPressed ( sf :: Keyboard :: Down) 

&& m_snake . GetDirection ( ) != Direction: :Up) 

{ 

m_snake . SetDirection (Direction : :Down) ; 

} else if ( sf :: Keyboard :: isKeyPressed ( sf :: Keyboard :: Left ) 

&& m_snake . GetDirection ( ) != Direction :: Right ) 

{ 

m_snake . SetDirection (Direction : :Left) ; 

} else if (sf :: Keyboard :: isKeyPressed ( sf :: Keyboard :: Right ) 

&& m_snake . GetDirection ( ) != Direction :: Left ) 

{ 

m_snake . SetDirection (Direction : :Right) ; 

} 

s opposite 
ions it can 

go in, and the use of the GetDirection ( ) method ensures that we don't send the 
nation of 
gh the use of 

the SetDirection ( ) method. 

Let's get things moving by updating both our classes: 
void Game :: Update () { 

float timestep = l.Of / m_snake . GetSpeed ( ) ; 

if (m_elapsed >= timestep) { 
m_snake . Tick ( ) ; 
m_world . Update (m_snake) ; 
m_elapsed -= timestep; 
if (m_snake . HasLost ( ) ) { 


[ 54 ] 



Chapter 3 


m_snake . Reset ( ) ; 

} 

} 


} 

As mentioned previously, we're using fixed time-step here, which incorporates the 
d. This is 
if he has. 

We're really close now. Time to draw everything on screen: 

void Game: : Render () { 

m_window . BeginDraw ( ) ; 

// Render here. 

m_world . Render ( *m_window . GetRenderWindow ( ) ) ; 
m_snake . Render ( *m_window . GetRenderWindow ( ) ) ; 

m_window . EndDraw ( ) ; 

} 

Much like before, we simply invoke the Render methods of both our classes and 
pass in a reference to sf : : RenderWindow. With that, our game is actually playable! 
up with 

something looking like this following image: 



The snake will be still at first, until one of the four arrow keys is pressed. Once it 
does start moving, it will be able to eat the apple and grow by one segment, collide 
the player 

crashes into a wall. The core version of our game is complete! Pat yourself on the 
back, as you just created your first game. 
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Hunting bugs 

As proud and satisfied as you may be with your first project, nothing is ever perfect, 
d an odd 

event when quickly mashing the buttons, looking something like this: 



eems that 
missing its tail. 

What happened? Try to figure it out on your own before continuing, as it perfectly 
illustrates the experience of fixing game flaws. 

n our 
quickly: 

• The snake is facing right. 

• Any arrow key other than the left or right is pressed. 

• The direction of the snake gets set to something else, let's say up. 

• The right key is pressed before the game has a chance to update. 

• Since the snake's direction is no longer set to right or left, if statement in 
the input handler is satisfied and sets the direction to left. 

• The game updates the snake and moves it left by one space. The head 
collides with its tail and it gets cut off. 

Yes, it seems that our direction checking is flawed and causes this bug. Once again, 
spend some time trying to think of a way to fix this before moving on. 
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Fixing bugs 

ike this. First, 

the programmer might think about putting a flag somewhere that remembers if the 
afterwards. This 

would prevent the bug we're experiencing, but would also lock down the number 
second. That 

would mean that if you press a key at the beginning of that second, you wouldn't be 
able to change your mind and hit another key quickly to rectify your wrong decision 
before the snake moves. That's no good. Let's move on to a new idea. 

Another approach may be to keep track of the original direction before any changes 
were made to that iteration. Then, once the update method gets called, we could 
posite of the 
t and move the 

snake in the direction before any changes were made. This would fix the bug and 
not present us with a new one, but it comes with keeping track of one more variable 
and might get confusing. Imagine that in the future you're presented with a similar 
bug or a request for a feature that needs you to keep track of another variable on 
soon, your 

checking statement might look a little something like this: 

if (varl != something && var2 == something && var3 == true && var4 == 

! var3 . . . ) 

ck the 

same variables four times for four different conditions. It quickly becomes apparent 
that this is a bad design and it shouldn't be used by anyone with intentions of ever 
showing their code to another person. 

ot rely 
and instead 
on it's facing, 
as shown next: 

Direction Snake: : GetPhysicalDirection ( ) { 
if (m_snakeBody . size ( ) <= 1) { 
return Direction : :None ; 

} 

SnakeSegment& head = m_snakeBody [0] ; 

SnakeSegment& neck = m_snakeBody [1] ; 

if (head . position . x == neck . position . x) { 

return (head . position ,y > neck . position . y 
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? Direction :: Down : Direction: :Up) ; 

} else if (head. position. y == neck . position . y) { 
return (head . position . x > neck . position . x 
? Direction :: Right : Direction :: Left) ; 

} 


return Direction : :None ; 

} 

First, we check if the snake is 1 segment long or less; in this case, it doesn't matter 
ead, and it 
all. Assuming 
neck, 

mply check 
acing using 
ated in the 
following image: 


Head.x == Neck.x 

^-+x 


Head.y == Neck.y 

►h-x 

■ Head.x > Neck.x 
I Di recti on - RIGHT 


: 


I Head . y < Neck . y 
Direction - up 

Head.y > Neck.y 
Di recti on - down 




Head.x < Neck.x 
Direction - left 


+y 


ke moves, 

so let's adjust our input handling code to cater to these changes: 

if ( sf : : Keyboard : : isKeyPressed (sf : : Keyboard : : Up) 

&& m_snake . GetPhysicalDirection ( ) != Direction :: Down) 

{ 

m_snake . SetDirection (Direction : :Up) ; 

} else if (sf :: Keyboard :: isKeyPressed ( sf :: Keyboard :: Down) 
&& m_snake . GetPhysicalDirection ( ) != Direction :: Up) 

{ 

m_snake . SetDirection (Direction : :Down) ; 

} else if (sf :: Keyboard :: isKeyPressed ( sf :: Keyboard :: Left ) 
&& m_snake . GetPhysicalDirection ( ) != Direction :: Right ) 

{ 

m_snake . SetDirection (Direction : :Left) ; 

} else if (sf :: Keyboard :: isKeyPressed ( sf :: Keyboard :: Right ) 
&& m_snake . GetPhysicalDirection ( ) != Direction :: Left) 
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{ 

m_snake . SetDirection (Direction : : Right) ; 

} 


Voila! No more of our snake turning inside out. 
urpose. Try 

to find it and fix it in order to practise resolving problems like this in the future. 

Hint: It has to do with how many segments the snake has when the 
game starts. 

If you want to do this one fairly, do your best not to reference the code of the finished 
project that came with this book, as that has it fixed already. 

Going the extra mile 

A functional game is far from a fully finished product. Sure, we have everything we 
wanted in the beginning, but it still leaves things to be desired, such as keeping track 
of the score and showing how many lives we have. At first, your main instinct might 
the number of 
rinting it out 
o change your 

way of thinking by introducing something that we will be using and improving 
over the course of this book: the textbox. 

window on 

any given communication application, such as MSN Messenger or Skype. Whenever a 
new message is added, it's added to the bottom as the older messages are moved up. 
The window holds a certain number of messages that are visible at one time. That's 
ut can also 

be used for debugging. Let's start by writing our header, as usual: 
using MessageContainer = std : : vector<std : : string> ; 



class Textboxj 
public : 

Textbox ( ) ; 

Textbox (int l_visible, int l_charSize, 
int l_width, sf::Vector2f l_screenPos) ; 
-Textbox ( ) ; 

void Setup (int l_visible, int l_charSize, 
int l_width, sf::Vector2f l_screenPos) ; 
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void Add (std :: string l_message) ; 
void Clear ( ) ; 

void Render (sf :: RenderWindow& l_wind) ; 
private : 

MessageContainer m_messages; 
int m_numVisible ; 

sf : : RectangleShape m_backdrop; 
sf : : Font m_font ; 
sf::Text m_content; 

} ; 


We begin by defining the data type for the container of all the messages. In this case, 
we went with std : : vector again, simply because that's the more familiar choice 
at this point. Just to make it look better and more readable, we've added a rectangle 
. On top of 

that, we have introduced a new data type: sf : : Text. This is a drawable type that 
usted in size, 

font, and color, as well as transformed, much like any other drawable in SFML. 

Let's start implementing our fancy new feature: 

Textbox : : Textbox ( ) { 

Setup (5,9,200,sf: : Vector2f (0,0)); 

} 


Textbox :: Textbox ( int l_visible, int l_charSize, 
int l_width, sf::Vector2f l_screenPos ) { 

Setup (l_visible , l_charSize, l_width, l_screenPos) ; 

} 


Textbox :: -Textbox () { Clear (); } 

As you can see, it has two constructors, one of which can be used to initialize some 
e values as 

arguments. The first argument is the number of lines that are visible in the textbox. 
It is followed by the character size in pixels, the width of the entire textbox in pixels, 
and fl drawn 

at. All that these constructors do is invoke the Setup method and pass all these 
arguments to it, so let's take a look at it: 

void Textbox :: Setup ( int l_visible, int l_charSize, 
int l_width, sf::Vector2f l_screenPos) 

{ 
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m_numVisible = l_visible; 

sf::Vector2f l_of f set (2 . Of , 2. Of); 

m_f ont . loadFromFile ( " arial . ttf " ) ; 

m_content . setFont (m_font) ; 

m_content . setstring ( " " ) ; 

m_content . setCharacterSize (l_charSize) ; 

m_content . set Color (sf : : Color : : White) ; 

m_content . setPosition (l_screenPos + l_offset) ; 

m_backdrop . setSize ( sf : : Vector2f ( 

l_width, (l_visible * (l_charSize * 1.2f)))); 
m_backdrop .setFillColor(sf: :Color(90,90,90,90)) ; 
m_backdrop . setPosition (l_screenPos) ; 

} 

Aside from initializing its member values, this method defines an offset float vector 
that will be used to space the text appropriately and provide some padding from 
the top-left corner. It also sets up our sf : : Text member by first creating a font to 
which it's bound, setting the initial string to nothing, setting up the character size 
on argument 
the backdrop 

by using the width that was provided and multiplying the number of visible lines 
floating point 

value of 1.2, in order to account for spacing between the lines. 

From time to time, it does simply come down to playing with code to 
n order 

to determine the correct value. Don't be afraid to try out new things and 
see what works. 



Since we're utilizing a vector to store our messages, adding a new one or removing 
them all is as simple as using the pushjoack and clear methods: 

void Textbox :: Add ( std :: string l_message) { 
m_messages .push_back (l_message) ; 
if (m_messages . size ( ) < 6) { return; } 
m_messages . erase (m_messages . begin ( ) ) ; 

} 


void Textbox :: Clear () { m_messages . clear () ; } 
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In the case of adding a new message, checking whether we have more of them than 
going to 

see or need ever again is wasteful, so the very first message that is definitely out of 
sight at that time is removed from the message container. 

We're very close to actually finishing this neat feature. The only thing left now is 
drawing it, which, as always, is taken care of by the Render method: 

void Textbox :: Render ( sf :: RenderWindow& l_wind) { 

std: : string l_content ; 

for(auto &itr : m_messages) { 
l_content . append ( itr+ " \n" ) ; 

} 

if(l_content != ""){ 

m_content . setstring (l_content) ; 
l_wind . draw (m_backdrop) ; 
l_wind . draw (m_content ) ; 

} 

} 


The code begins with std : : string being set up to hold all the visible messages 
on the screen. Afterwards, it's as simple as looping over the message vector and 
appending the text of each message to our local std : : string variable with a new 
king sure it 

isn't empty, we must set our m_content member of type sf : : Text to hold the string 
text on 

the screen. That's all there is to the Textbox class. 

After adding an instance of Textbox as a member to our game class, we can start 
setting it up: 

Game : : Game ( ) ... { 


m_textbox. Setup (5, 14, 350, sf: : Vector2f (225,0)); 

m_textbox . Add (" Seeded random number generator with: " + std:: to 
string (time (NULL) ) ) ; 

} 
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After passing some constant values to the Setup method of our m_textbox 
member, we immediately start using it right there in the constructor by actually 
outputting our first message. Let's finish integrating it fully by making one last 
adjustment to the Game : : Render ( ) method: 

void Game: : Render () { 

m_window . BeginDraw ( ) ; 

// Render here. 

m_world . Render ( *m_window . GetRenderWindow ( ) ) ; 
m_snake . Render ( *m_window . GetRenderWindow ()); 
m_textbox . Render ( *m_window . GetRenderWindow ( ) ) ; 

m_window . EndDraw ( ) ; 

} 


that the text 
everything 

else. After adding more messages to the game to be printed and compiling our 
project, we should end up with something like this: 


Seeded random number generator with: 1425363706 

GAME OVER! Score: 0 

You ate an apple. Score: 10 

You ate an apple. Score: 20 

GAME OVER! Score: 20 


game that we 

will be covering in this book. Feel free to play around with it and see what else you 
can come up with to spice up the game! 


Common mistakes 

A fairly common thing people often forget is the following line: 
srand ( time (nullptr) ) ; 

If you notice, the numbers being generated are exactly the same each time you 
nerator 

or you haven't provided a proper seed. It's recommended to always use a unix 
timestamp, as shown. 


[ 63 ] 




Get Your Hands Dirty - What You Need to Know 


The use of this particular random function should be restricted to 
something that isn't related to security and cryptography. Using it 
in combination with the modulus operator can produce incredibly 
non-uniform results due to the introduced bias. 

Another fairly common problem is the programmers 1 choice of the data container 
to hold their structures. Let's take the following for example: 

using SnakeContainer = std : : vector<SnakeSegment> ; 

This defines the type of our SnakeContainer. If you've compiled the code we've 
written, you will notice that it runs fairly smoothly. Now consider this next line 
of code: 

Using SnakeContainer = std : : deque<SnakeSegment> ; 

Because of the way these two containers are implemented in STL, nothing 
else changes in our code, so feel free to try to change the data type of your 
SnakeContainer from std: : vector to std: : deque. After compiling and running the 
project, you will definitely pick up on the hit on performance. Why is that happening? 
Well, even though std : : vector and std : : deque can be used basically in the same 
way, they're fundamentally different under the hood. The vector offers the certainty 
of its elements being contiguous in memory, while the double ended queue does not. 
There are also differences in performances, depending on where the most inserts and 
removals are done. If you're unsure about which container to use, make sure to either 
look it up or benchmark it yourself. Never just blindly assume, unless performance 
isn't the main concern to you. 

change, 
take you 

can make is the mistake of not learning by breaking and fixing things. Consider the 
fic recipe. If 

understanding something better means you have to break it first, so be it. 
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Summary 

Game development is a great journey to embark on. You had taken your first and 
second steps earlier, but now you have boarded the plane with your first, fully 
functional game in the bag. You are now officially a game developer! Where will this 
plane of opportunity take you and how long will it be there for? All of that is entirely 
st to inspire 
eriences to 

be had there. One thing is definitely for sure, however, and that is that this is not the 
to head to, 
and that's forward. 

A lot was covered in this chapter, and now it's impossible to say that you haven't 
gotten your hands dirty while paying homage to one of the all time arcade classics. 

In the next chapter, we will take on input handling and event management in 
order to provide flexibility and fluent means of interaction between you and your 
w chapters. 

There's still a lot to learn and many lines of code to write, so don't spend too much 
time hesitating to proceed onto the next chapter. A brand new adventure is waiting 
to unfold. See you there! 
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ing able 

to play it. Regardless of the purpose of input, ranging from simply hitting keys to 
ich 

y for you 

to interact with it might as well leave you with a very fancy screensaver. We have 
very briefly looked at the primitive way of grabbing and using the keyboard input, 
eing content 

with a large nest of if/ else statements that handle every single key being pressed. 
Instead, we want to look at a more robust way of handling not just the keyboard, but 
adding 
cks. With that 

in mind, let's take a look at what we will be covering in this chapter: 

• Basic means of checking the states of keyboard and mouse buttons 

• Understanding and processing different types of events 

• Understanding and utilizing callbacks 

• Designing and implementing an event manager 

Let's not sit still like the character of your game without input and get on coding! 
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Retrieving peripheral input 

etrieving 

peripheral output a little bit, and, ironically enough, the entire scope of the class was 
covered. Just to recap, sf : : Keyboard is a class that provides a single static method 
isKeyPressed ( sf : : Keyboard : : Key) to determine the real-time state of a certain 
nted 

by the sf : : Keyboard : : Key enumeration table. Because this method is static, 
sf : : Keyboard doesn't need to be instantiated and can be used as follows: 

if ( sf : : Keyboard : : isKeyPressed ( sf : : Keyboard : : W) ) { 

//Do something if the W key is pressed. 

} 

it does 

lend itself to quite a bit of a mess of if/else statements if we want to check for 
more keystrokes. 

Checking for mouse input 

Predictably enough, SFML also provides a class similar to sf : : Keyboard with the 
same idea of obtaining real-time status of a mouse: sf : : Mouse. Much like its partner 
being 

pressed, as shown next: 

if (sf : : Mouse : : isButtonPressed (sf : : Mouse : : Left ) ) { 

//Do something if the left mouse button is pressed. 

} 

The sf : : Mouse class provides its own enumeration of possible buttons on any given 
mice, of which we have a grand total of five: 


Sf : 

: Mouse : 

Left 

The left mouse button 

Sf : 

: Mouse : 

Right 

The right mouse button 

Sf : 

: Mouse : 

Middle 

Mouse wheel being clicked 

Sf : 

: Mouse : 

XButtonl 

First extra mouse button 

Sf : 

: Mouse : 

XButton2 

Second extra mouse button 


In addition to that, the sf : : Mouse class provides a way to get and set the current 
mouse position: 

// Getting the mouse position. 

sf::Vector2i mousePos = sf :: Mouse :: getPosition () ; // 1 
sf::Vector2i mousePos = sf :: Mouse :: getPosition (m_window) ; // 2 
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// Setting the mouse position. 

sf : :Mouse : : setPosition (sf : : Vector2i ( 0 , 0) ) ; // 3 

sf :: Mouse :: setPosition ( sf :: Vector2i ( 0 , 0 ), m_window) ; // 4 

Both these methods have an overloaded version that takes in a reference to a 

lative 

ation: 


X 


Desktop origin (0,0) 



ious example, 
rigin to 
vided, the 
location, 
window. The 
gets set to the 

provided int vector argument. 

Plug in your controller 

Yes, as the title states, SFML supports input not only from your keyboard and 
to your 

computer. By utilizing the class sf : : Joystick, which only contains static methods, 
just like the previous two classes, it is possible to check if a controller is connected, 
ain axes, 

if the controller supports that. 
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ame time, 

which are identified by a numerical index in the range of [0 ; 7 \. Because of that, every 
method that sf : : Joystick provides has to have at least one argument, which is the 
oiler is connected: 

if (sf : : Joystick : : isConnected (0) ) 

{ 

//We have a controller with an id 0. 

} 

t actually 

supports, as follows: 

unsigned int n_buttons = sf :: Joystick :: getButtonCount ( 0 ) ; 

Because there is no other way to abstractly define the buttons for every controller 
on the planet, they're simply referred to by numeric indices between 0 and 31. 
Checking for a button push can be done by calling the isButtonPressed ( ) 
method, as shown next: 

if (sf : : Joystick : : isButtonPressed (0 , 1) ) { 

// Button 1 on controller 0 is pressed. 

} 

In order to check if a controller supports a specific axis, we can use the hasAxis ( ) 
method: 

if (sf : : Joystick: :hasAxis (0, sf : : Joystick: :X) ) { 

// Controller 0 supports movement on X axis. 

} 

The sf : : Joystick : : Axis enumeration encapsulates all the possible axes that a 
controller could support, so one can check for that as shown in the preceding code, 
g an axis can 
be done as follows: 

float p_x = sf :: Joystick: : getAxisPosition ( 0 , sf :: Joystick :: X) ; 
float p_y = sf :: Joystick: :getAxisPosition(0, sf :: Joystick :: Y) ; 

//Do something with p_x and p_y. 

es on the 
controller 0. 
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Because the sf : : Joystick states are updated when checking for events, 
it might present some problems when using any of these methods before 
t to 

manually call the sf : : Joystick : Update ( ) method in order to make 
sure you have the latest state of your peripherals. 


Understanding the sf::Event 

Once again, sf : : Event is something we briefly touched on, however, it's imperative 
to expand on it and understand it better before proceeding, if we want to build a 
s. First, 

let's reiterate what an event is. sf : : Event is a union, which in C++ terms means 
that it's a special class which can hold only one of its non-static data members at a 
time, of which it has several, such as KeyEvent, which holds the information about a 
keyboard event, sizeEvent, which holds information about the size of our window 
that got resized, and many others. Because of this nature of sf : : Event, it can be a 
ssing the 

KeyEvent struct inside sf : : Event, when that is not the active data member. Since 
all the members of a union share the same memory space, this results in undefined 
ing. 

Let's take a look at the most basic way of processing events: 
sf : : Event event ; 

while (m_window . pollEvent (event) ) { 
switch (event . type) { 
case sf :: Event :: Closed : 
m_window. close ( ) ; 
break ; 


case sf :: Event :: KeyPressed : 

if (event . key . code == sf :: Keyboard :: W) { 

//Do something when W key gets pressed once. 

} 

break ; 

} 

} 
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Nothing we haven't seen before, although it's important we fill in the blanks of what 
exactly is going on. First, the sf : : Event instance named event gets filled out by the 
pollEvent ( ) method. Based on its type, it will choose one of the structures in the 
union to be the active one to carry the data relevant to the event. Afterwards, we can 
check for the type of the event, which is defined by the sf : : Event : : Type enumeration 
table and make sure we're using the correct data member to obtain the information 
we need. As mentioned before, trying to access event . key . code if the event type is 
sf : : Event : : Closed, for example, would result in an undefined behavior. 



Remember, using the sf : : Event : : KeyPressed event for something 
like real-time character movement is a bad idea. This event gets 
dispatched only once before a small delay is applied and then it gets 
dispatched again. Think of a document editor here. When you press 
down on a key and hold it, at first it only shows a single character before 

for any action that needs to be continuous as long as the key is being 
held down is not even close to optimal and should be replaced with 
sf : : Keyboard : : isKeyPressed ( ) in order to check the actual state 
of the key. The same idea applies to the mouse and controller input. 


keystroke, but not much else. 


h the same 

as the input example was before, it can get out of hand quickly on a larger scale. Let's 
device the way 

we did in the previous project is a nightmare. Still not convinced? Imagine having 
an application where you want to check for multiple keys being pressed at the same 
ude events 
tain event 
other layer of 

complexity, but nothing you can't handle, right? Throwing in some Boolean flags in 
there to keep track of the event states or maybe the keystrokes shouldn't be too hard. 

Some time passes and the application now needs support for loading key 
combinations from a file in order to make your approach more dynamic and 
customizable. You have a mess on your hands. You can build it, but it's going to be 
that you 

are likely to just throw your arms in the air and give up. Why put yourself through 
p with an 

automated approach that will need no flags, is flexible, can load any combination of 
keys and events from a file, and still keep your code just as neat and clean as it was 
g on a system 

that will handle all of these headaches for us. 
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Introducing the event manager 

Figuring out what we want from our application is the first and the most crucial part 
of the design process. Sometimes it's difficult to cover all your bases, but forgetting 
about a feature that might alter the way all the code is structured and trying to 
into your 
ur event 

manager to have: 

• The ability to couple any mix of keys, buttons, or events (from now on 
ing 

• Binding of the said functionalities to methods that get called if all the 
icked, 

or the window losing focus, for example) for the binding are satisfied 

• A way through which the event manager can deal with actual SFML events 
being polled 

• Loading the bindings from a configuration file 

We have our specifications, now let's start designing! We'll be using the 
EventManager . h file to include all the little bits and pieces that make this possible 
on top of having the definition of the class. The first thing that we need to define is 
all the types of events we'll be dealing with. This can be extended later on, but as this 
hat just yet. 

Let's write the enumeration table: 

enum class EventType{ 

KeyDown = sf :: Event :: KeyPressed, 

KeyUp = sf :: Event :: KeyReleased, 

MButtonDown = sf :: Event :: MouseButtonPressed, 

MButtonUp = sf :: Event :: MouseButtonReleased, 

MouseWheel = sf :: Event :: MouseWheelMoved, 

WindowResized = sf :: Event :: Resized, 

GainedFocus = sf :: Event :: GainedFocus , 

LostFocus = sf :: Event :: LostFocus , 

MouseEntered = sf :: Event :: MouseEntered, 

MouseLeft = sf :: Event :: MouseLeft , 

Closed = sf :: Event :: Closed, 

TextEntered = sf :: Event :: TextEntered, 

Keyboard = sf :: Event :: Count + 1, Mouse, Joystick 

}; 
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re the 

enumeration is terminated. We're setting up our own event, called Keyboard to 
the value of sf : : Event : : Count + l. Because all the enumerations are essentially 
keywords pointing to integer values, the last row prevents any kind of identifier 
an the 

absolute maximum sf : : Event : : EventType enumeration value. As long as anything 
hes. 



The sf : : Event enumeration values can be different, depending on 
which version of SFML you are using! 


] 


nding. We 

know that in order to bind to a key, we need both the event type and the code for the 
key that we're interested in. Some events we'll be working with only need to have a 
th the type. 

Knowing that, let's define a new structure that will help us store this information: 

struct EventInfo{ 

EventInfo(){ m_code =0; } 

Eventlnf o ( int l_event) { m_code = 1 event; } 
union{ 

int m_code; 

} ; 

} ; 


In order to leave room for expansions, we're already using a union to store the event 
code. Next, we can set up the data type that we're going to be using to hold the event 
information: 

using Events = std : : vector<std : :pair<EventType , EventInfo>>; 
hat uses this 

class, now is as good a time as any to set up a data type that will help us do that: 
struct EventDetails { 

EventDetails (const std strings l_bindName) 

: m_name (l_bindName) 

{ 

Clear ( ) ; 

} 

std:: string m_name; 

sf::Vector2i m_size; 

sf : :Uint32 m_textEntered ; 
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sf::Vector2i m_mouse; 

int m_mouseWheelDelta ; 

int m_keyCode; // Single key code. 

void Clear ( ) { 

m_size = sf : : Vector2 i ( 0 , 0); 
m_textEntered = 0; 
rrwnouse = sf : : Vector2i ( 0 , 0); 
rrwnouseWheelDelta = 0; 
m_keyCode = - 1 ; 

} 

} ; 

1 the event 

information. Seems quite simple, so let's implement it: 

struct Binding{ 

Binding (const std::string& l_name) 

: m_name ( l_name ) , m_details (l_name) , c(0){} 
void BindEvent (EventType l_type, 

Eventlnfo l_info = EventlnfoO) 

{ 

m_events . emplace_back (l_type , l_info) ; 

} 


Events m_events; 
std:: string m_name ; 

int c; // Count of events that are "happening". 
EventDetails m_details; 

} ; 


to and uses 

the initializer list to set up the class data members. We also have a BindEvent ( ) 

ucture 

we haven't 

mentioned before is the integer with the name c. As the comment suggests, this 
keeps track of how many events are actually taking place, which will be useful later 
on". Lastly, this 

is the structure where the event detail data member that gets shared around resides. 
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These bindings will also have to be stored somehow, so let's define the data type for 
the container that will take care of it: 

using Bindings = std :: unordered_map<std :: string, Binding*>; 

Using std : : unordered_map for our bindings guarantees that there will only be one 
ame string is 

the key for that container. 

We're doing great so far, however, without a way to actually tie these actions to 
talk about how 

we could implement this. In the world of computer science, every now and then 
you've probably heard the term "callback" being thrown around. In simplest terms, 
her piece 

of code, which will execute it at a convenient time. In the case of our event manager, 
tic action are 

happening, and the callback is a method that represents the action being performed, 
uld create 

a binding with a name "Jump", which is our action name, and add a single event of 
type KeyDown and code sf : : Keyboard : : Space to it. For argument sake, let's say 
the character has a method called Jump ( ) . That's our callback. We want to bind that 
method to the name "Jump" and have the event manager call the character's Jump ( ) 
going to be 

handling input with this new system, 
nction 

pointers". While that's not necessarily a bad option, it can get a little messy if you're 
rio of 

adding a method of a class as a callback. Pointers to the class members aren't exactly 
a basic 

definition of a member function pointer: 

void (SomeClass : :*_callback) () ; 

Already this shows a few major limitations. For one, we can only have pointers to 
methods of the class "SomeClass". Secondly, without having an instance to the class 
that has the method we're pointing to, it's quite useless. A thought has probably 
ction 

pointer in some callback structure. Let's take a look: 

struct Callback! 

std::string m_name; 

SomeClass* Callbacklnstance ; // Pointer to instance, 
void (SomeClass : :*_callback) () ; 
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} ; 


're still limited 

to only one class. We could just wrap every other class method call in the methods 
of the "SomeClass" class, but that's tedious and more importantly, it's a bad practice. 
Maybe now you're thinking that some template magic might solve this problem, 
ty and the 

mess that it might create. Consider the most minimum amount of effort this could 
possibly take: 

template<class T> 
struct Callback! 


T* Callbacklnstance; // Pointer to instance. 
void(T: :*_callback) () ; 


} ; 


This by itself doesn't solve anything, but instead it only brings more problems. For 
one, you now have to define that template in your event manager class, which is 
means 

having to template the entire event manager class, which locks it down to one class 
type. We're right back to where we started. Using typedef would be a clever idea, 
this form: 

template <class T> 

using Function = void ( T : : * ) (); 

There are some hackish workarounds for non C++11 compilers, like wrapping 
typedef in struct after defining the template. However, that doesn't solve our 
iler even 

crashing when using "templated" member function pointer type definitions. This is 
quite a mess, and at this point you're probably thinking about simply going back 
all in a 
an that. 
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Standard function wrapper 

solve this 

pickle elegantly: std : : function and std : : bind. The std : : function type is a 
it 

take a 

look at a minimal example of using it: 

#include <functional> // Defines std :: function & std::bind. 

std :: function<void (void) > foo = std :: bind ( &Bar :: methodl , this); 

In this case, we're instantiating a function wrapper called "foo", which holds a 
function with the signature void (void) . On the right side of the equals sign, we 
use std: : bind to bind the member function "methodl" of the class "Bar" to the 
foo is the 
. In this case, 

it has to be an instance of the Bar class, so let's imagine this line of code is written 
somewhere in the implementation of it and just pass in "this". Now our foo object 
is bound to the method methodl of class Bar. Because std : : function overloads 
the parenthesis operator, calling it is as easy as this: 

foo(); // Equivalent to barlnstance- >methodl ( ) ; 

Now we can finally define the type of the callback container: 

using Callbacks = std :: unordered_map< std :: string, 
std : : function<void (EventDetails* ) >> ; 

Once again, using std: :unordered_map ensures that there's only one callback per 
action. This can be changed later if needed. 

Building the event manager 

At this time, we have everything we need to actually write the header of our event 
manager class. Given all the design decisions we made previously, it should come 
out looking something like the following: 

class EventManager { 
public : 

EventManager ( ) ; 

-EventManager ( ) ; 

bool AddBinding (Binding *l_binding) ; 
bool RemoveBinding ( std :: string l_name) ; 
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void SetFocus (const bool& l_focus) ; 

// Needs to be defined in the header! 
template<class T> 

bool AddCallback (const std::string& l_name, 

void (T : : *l_func) (EventDetails* ) , T* l_instance) 

{ 

auto temp = std : : bind (l_func , l_instance , 
std : :placeholders : : 1 ) ; 

return m_callbacks . emplace ( l_name , temp) .second; 

} 

void RemoveCallback (const std::string& l_name) { 
m_callbacks . erase (l_name) ; 

} 


void HandleEvent ( sf Events l_event); 
void Update ( ) ; 


sf::Vector2i GetMousePos ( sf ; : RenderWindow* l_wind = nullptr) { 
return (l_wind ? sf Mouse getPosition ( *l_wind) 

: sf :: Mouse :: getPosition ()) ; 

} 


private : 

void LoadBindings ( ) ; 


} ; 


Bindings m_bindings; 
Callbacks m_callbacks; 
bool m_hasFocus; 


As you can gather from looking at the class definition, we still needed to use a 
templated member function pointer argument for the AddCallback ( ) method. The 
use of std : : function, however, isolates this to a single method, meaning we don't 
pointers to 
r that will 

be replaced by an argument in the future, are bound to a temporary function, we 
eals with the 

templated classes, we need to implement our template AddCallback ( ) method in 
the header file, instead of the .cpp file. Just for the sake of consistency, and because 
it's a really simple method, we define RemoveCallback ( ) in the header file too. 
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The other thing worthy of pointing out about the header is the implementation of 
the method that will be used to obtain the position of the mouse: GetMousePos ( ) . 

It takes a pointer to a type of sf : : RenderWindow, in case we want the coordinates 
returned to be relative to a specific window. The same window can also have or lose 
focus, so a flag m_hasFocus is kept around to keep track of that. 

Implementing the event manager 

Let's get started with actually implementing all the event manager class methods, 
starting, as always, with the constructor and destructor: 

EventManager : : EventManager ( ) : m_hasFocus (true) { LoadBindings ( ) ; } 

EventManager : : -EventManager ( ) { 
for (auto &itr : m_bindings) { 
delete itr. second; 
itr. second = nullptr; 


} 

The constructor's job in this case is really simple. All it has to do is call a private 
method LoadBindings ( ) , which is used to load the information about our bindings 
from a file. We will cover that shortly. 

ss. If you recall, 

Located. 

Let's take a gander at the AddBinding method implementation: 

bool EventManager :: AddBinding (Binding *l_binding) { 

if (m_bindings . f ind ( l_binding- >m_name) != m_bindings . end ( ) ) 
return false; 

return m_bindings . emplace ( l_binding- >m_name , 
l_binding) .second; 

} 

As you can see, it takes in a pointer to a binding. It then checks if the binding 

od returns 

falsenew 

binding gets inserted into the container. 
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We have a way to add the bindings, but what about removing them? That's where 
the RemoveBinding method comes in: 

bool EventManager :: RemoveBinding ( std :: string l_name) { 
auto itr = m_bindings . f ind (l_name) ; 
if (itr == m_bindings . end ( ) ) { return false; } 
delete itr->second; 
m_bindings . erase ( itr) ; 
return true; 

} 

store into 

an iterator. If a match is found, it first frees up the memory by deleting the second 
before 

returning true for success. Easy. 

As mentioned in the specifications for designing this class, we need a way to process 
the SFML events that are being polled in each iteration in order to look at them 

HandleEvent 

comes in: 


void EventManager :: HandleEvent ( sf :: Events l_event) { 
// Handling SFML events, 
for (auto &b_itr : m_bindings) { 

Binding* bind = b_itr . second ; 

for (auto &e_itr : bind- >m_events ) { 

EventType sfmlEvent = (EventType) l_event . type; 
if (e_itr. first != sfmlEvent) { continue; } 
if (sfmlEvent == EventType :: KeyDown | 
sfmlEvent == EventType KeyUp) 


{ 


if (e_itr . second . m_code == l_event . key . code 
// Matching event /keystroke . 

// Increase count, 
if (bind- >m_details . m_keyCode 
bind- >m_details . m_keyCode = 


!= - 1 ){ 

e itr. second. m code; 


} 

++ (bind->c) ; 
break ; 

} 

} else if (sfmlEvent == EventType :: MButtonDown 
sfmlEvent == EventType : :MButtonUp) 

{ 


[ 81 ] 



Grab That Joystick - Input and Event Management 


if (e_itr . second . m_code == l_event . mouseButton . button) { 

// Matching event /keystroke . 

// Increase count. 

bind- >m_details . m_mouse . x = l_event . mouseButton . x ; 
bind- >m_details . rrwnouse ,y = l_event . mouseButton .y; 
if (bind- >m_details . rrwkeyCode != -1) { 

bind- >m_details . m_keyCode = e_itr . second . m_code ; 

} 

++ (bind->c) ; 
break ; 

} 

} else { 

// No need for additional checking, 
if (sfmlEvent == EventType : : MouseWheel ) { 
bind- >m__details . rrwnouseWheelDelta = 
l_event . mouseWheel . delta ; 

} else if (sfmlEvent == EventType :: WindowResized) { 
bind- >m_details . m__size . x = l_event.size.width; 
bind- >m_details . m_size . y = l_event . size . height ; 

} else if (sfmlEvent == EventType :: TextEntered) { 

bind- >m_details . m_textEntered = l_event . text . Unicode ; 

} 

++ (bind->c) ; 

} 

} 

} 

} 

It takes in, appropriately enough, an argument of type sf : : Event. This method 
the binding 

to check if the type of the l_event argument matches the type of the binding event 
that's currently being processed. If it does, we check if it's a keyboard event or a 
s or the 
, the last 
e, which are 

respectively stored in the l_event . key and l_event .mouseButton structs, match 
the code of our binding event. With that being the case, or if it's a different type of 
es down, 

we increment the member c of the binding instance to signify a match shortly after 
he binding. 
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n handle 

real-time input checking as well as the validating and resetting of the states of the 
bindings. Let's write it: 

void EventManager :: Update () { 
if ( ! m_hasFocus ) { return; } 
for (auto &b_itr : m_bindings) { 

Binding* bind = b_itr . second; 
for (auto &e_itr : bind- >m_events ) { 
switch (e_itr. first) { 
case (EventType :: Keyboard) : 

if (sf Keyboard :: isKeyPressed ( 

sf : : Keyboard : ; Key (e_itr . second . m_code) ) ) 

{ 

if (bind- >m_details . mkeyCode != -1) { 

bind- >m_details . m_keyCode = e_itr . second . m_code ; 

} 

++ (bind->c) ; 

} 

break ; 

case (EventType : :Mouse) : 

if (sf : :Mouse : : isButtonPressed ( 

sf : : Mouse : : Button (e_itr . second . m_code) ) ) 

{ 

if (bind- >m_details . mkeyCode != -1) { 

bind- >m_details . m_keyCode = e_itr . second . m_code ; 

} 

++ (bind->c) ; 

} 

break ; 

case (EventType :: Joystick) : 

//Up for expansion, 
break ; 

} 

} 

if (bind- >m_events . size ( ) == bind->c) { 

auto callltr = m_callbacks . find (bind- >m_name) ; 
if (callltr != m_callbacks . end ( ) ) { 
callItr->second (&bind->m_details) ; 

} 

} 

bind->c = 0; 

bind- >m_details . Clear ( ) ; 

} 

} 
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Once again, we iterate over all the bindings and their events. In this case, however, 
we're only interested in Keyboard, Mouse, and Joystick, as those are the only 
for the 

type of event we're dealing with, and use the appropriate class to check for the 
input. Incrementing the c member of the binding class, as usual, is our way of 
registering a match. 

The fihes 

the number of events that are "on". If that's the case, we locate our callback in the 
m_callbacks container and invoke the second data member with the parenthesis 
operator, because it is an std : : function method wrapper, in turn officially 
implementing the callbacks. To it, we pass the address of the EventDetails 
rtant to reset 

the active event counter c to 0 for the next iteration because the state of any of the 
aluated. 

Lastly, if you looked at the code top to bottom, you probably noticed that the case 
even handle 
nded later 
rt for joysticks 

and have access to one, consider it to be homework after this chapter. 

Now that we have all this functionality, why not actually read in some binding 
information from a file? Let's take a look at the example configuration, named 
keys . cf g, that we will be loading in: 

Window_close 0 : 0 
Fullscreen_toggle 5:89 
Move 9:0 24:38 

licity, the 

layout for it will remain pretty basic here. Each line is a new binding. It starts with 
he event 
different 
and the 

beginning of the events. Let’s read this in: 

void EventManager : : LoadBindings () { 
std:: string delimiter = 


std: : if stream bindings; 
bindings . open ( "keys . cfg" ) ; 
if (! bindings . is_open ()) { 

std::cout << "! Failed loading keys. cfg." << std: : endu- 
re turn; 
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std::string line; 

while ( std :: getline (bindings , line) ) { 
std: : stringstream keystream (line ) ; 
std::string callbackName; 
keystream >> callbackName; 

Binding* bind = new Binding (callbackName) ; 
while (! keystream. eof ()) { 
std:: string keyval; 
keystream >> keyval; 
int start = 0; 

int end = keyval . find (delimiter) ; 
if (end == std :: string :: npos) { 
delete bind; 
bind = nullptr; 
break ; 

} 

EventType type = EventType ( 

stoi (keyval . substr (start, end - start))); 
int code = stoi (keyval . substr (end + delimiter . length () , 
keyval . find (delimiter , end + delimiter . length ()))) ; 
Eventlnfo eventlnfo; 
eventlnf o . m_code = code; 

bind- >BindEvent (type , eventlnfo) ; 

} 


if ( ! AddBinding (bind) ) { delete bind; } 
bind = nullptr; 

} 

bindings . close ( ) ; 

} 

We start by attempting to open the keys . cfg file. If it fails, this method spits out 
a console message notifying us about it. Next, we proceed into a while loop in 
order to read every single line in the file. We define an std : : stringstream object, 

>> operator. 

It uses the default delimiter of a space, which is why we made that decision for the 
configuration file. After obtaining the name of our binding, we create a new Binding 
into a 

while loop and using ! keystream. eof ( ) as an argument, we make sure that it loops 
until the std : : stringstream object reaches the end of the line it was reading. This 
loop runs once for each key:value pair, once again thanks to std : : stringstream 
and its overloaded >> operator using whitespaces as delimiters by default. 


[ 85 ] 



Grab That Joystick - Input and Event Management 


hat we 
in their 

respective local variables. It takes in parts of the string that got read in earlier in 
order to separate the key:value pair by splitting it at the delimiter character, which 
in this case was defined at the very top of this method as " : If that character is not 
found within the string, the binding instance gets deleted and the line gets skipped, 
because it is most likely not formatted properly. If that's not the case, then the event 
gets successfully bound and the code moves on to the next pair. 

ttempt to add 

the binding to the event manager. It is done in the if -statement in order to catch the 
error we talked about earlier relating to binding name clashes. If there is a clash, 
the binding instance gets deleted. 

As you probably already know, it's also important to close the file after using it, so 
that's the last thing we do before this method concludes. With that done, our event 
manager is finally complete and it's time to actually put it to work. 

Integrating the Event Manager class 

ed, it makes 

sense to keep it in our window class, where we actually do the event polling. After 
’s open, so it 
ke a slight 

adjustment to the Window class by adding a data member to it: 

class Window{ 
public : 

bool IsFocusedO; 

EventManager* GetEventManager ( ) ; 

void ToggleFullscreen (EventDetails* l_details) ; 

void Close (EventDetails* l_details = nullptr) ; 


private : 


} ; 


EventManager m_eventManager ; 
bool m_isFocused; 
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he full 

screen toggle method has been modified to take in the EventDetails structure as 
an argument. A close method is also added to our window class, as well as a flag 
losing the 

window itself is as simple as setting a single flag to true: 

void Window :: Close () { m_isDone = true; } 

Now it's time to adjust the Window : : Update method and pass in all the events being 
polled to the event manager: 

void Window: : Update () { 
sf : : Event event; 

while (m_window . pollEvent (event) ) { 

if (event. type == sf :: Event :: LostFocus) { 
m_isFocused = false; 
m_eventManager . SetFocus (false) ; 

} 

else if (event. type == sf :: Event :: GainedFocus ) { 
m_isFocused = true; 
m_eventManager . SetFocus (true) ; 

} 

m_eventManager . HandleEvent (event) ; 

} 

m_eventManager . Update ( ) ; 

} 

ndow 

will be properly handled. It also notifies the event manager if the focus of the 
window changes. 

Time to actually use the event manager! Let's do that in Window : : Setup by 
a 

new instance of the event manager: 

void Window : : Setup (...){ 

m_isFocused = true; // Default value for focused flag. 
m_eventManager- >AddCallback ( " Fullscreen_toggle " , 

&Window: : ToggleFullscreen, this) ; 
m_eventManager- >AddCallback ( "Window_close" , 

&Window: : Close, this) ; 

} 


[ 87 ] 



Grab That Joystick - Input and Event Management 


Let's refer back to the keys . cfg file. We define the Fullscreen_toggle action and 
set up a key:value pair of 5:89, which essentially gets broken down to the event type 
of KeyDown (the number 5) and the code for the F5 key on the keyboard (number 89). 
t we used. 

The other callback that gets set up is for the action window_close, which in the 
configuration file is bound to 0:0. The event type 0 corresponds to closed in the 
as well. 

Both these actions get bound to methods of the window class. Note the last argument 
in the AddCallback method, which is a this pointer referring to the current instance 
of the window. After successful compilation and launch, you should discover that 
hitting the F5 key on your keyboard toggles the full screen mode of the window and 
thing a little bit 
more fun with this now. 

Moving a sprite revisited 

Now that we have a fancy event manager, let's test it fully by moving a sprite to 
eft mouse 

button is pressed. Add two new data members to your Game class: m_texture and 
m_sprite. Set them up as discussed in the previous chapters. For our purposes, we'll 
just be re-using the mushroom graphic from the first few chapters. Now add and 
implement a new method in your game class called MoveSprite: 

void Game : :MoveSprite (EventDetails* l_details) { 
sf::Vector2i mousepos = 

m_window- >GetEventManager ( ) - >GetMousePos ( 
m_window- >GetRenderWindow ( ) ) ; 
m_sprite . setPosition (mousepos .x, mousepos. y) ; 
std : : cout << "Moving sprite to: " 

<< mousepos. x << 

<< mousepos. y << std::endl; 

} 

w from 

the event manager and store it in a local integer vector called mousepos. We then 

ut a little 

a test. Let's 

set up our callback: 

Game : : Game ( ) { 

// Texture and sprite setup. 
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m_window- >GetEventManager () - >AddCallback ( "Move" , 

&Game : : MoveSprite , this ) ; 

} 

We tie the action name Move to the MoveSprite method of the Game class and pass in 
a pointer to the current instance, just like before. Before running this, let's take a peek 
at the way the move action is defined in the keys . cfg file: 

Move 9:0 24:38 

The first event type corresponds to MButtonDown, which is the event of the left 
mouse button being pressed down. The second event type corresponds to the 
Keyboard event, which checks for real-time input through the sf : : Keyboard class. 
The number 38 is the left shift key code, corresponding to sf : : Keyboard : : LShif t. 

a sprite 

ck anywhere on 

the screen, it will magically move to that position! 
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Principles of use 

gn. Let's 

say, for example, that you only want a callback to be called once for a binding that 
involves the left shift and the R key. You wouldn't define both the event types as 
Keyboard 

keys are down. You also don't want to define both of them as KeyDown events, 
because that would mean that both of these events would have to be registered at the 
o happen 

g the Keyboard 

and KeyDown events so that the very last key to be pressed is the KeyDown type and 
the rest of the keys will be Keyboard types. In our example, it means that we would 
have the left shift key being checked through the sf : : Keyboard class, while the 
R first, 

however, consider the famous example of the key combination Ctrl + Alt + Del on 
your computer. It works that way, but if you hold the keys in reverse order, it would 
make sure 

that the Ctrl and Alt keys are always checked through the sf : : Keyboard class, while 
the Del key is registered through the event polling. 

e events aren't 

yet supported, such as the sf : : Event : : TextEntered event because additional 

d from the 

sf : : Event 

that require 

the said events. 


Common mistakes 

One of the most common mistakes the newcomers make when it comes to SFML 
input is using certain methods of checking the user input for the wrong tasks, such as 
xt input. 

Understanding the limitations of anything you use is the key to cultivating any kind 
e different 

mechanisms we've discussed in order to achieve optimal results. 

Another fairly common mistake people make is defining templates in the .cpp file 
instead of the header. If you are getting linking errors pertaining to a method that just 
so happens to utilize templates, such as the EventManager : : AddCallback ( ) method, 
make sure to move the implementation of the method and the definition of the 
template right to the header of your class, otherwise the compiler cannot instantiate 
the template and the method becomes inaccessible during the linking process. 
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of SFML 

are guilty of is not knowing how to correctly obtain the mouse coordinates that 
nates and 

experiencing weird behavior to grabbing the coordinates relative to the desktop as 
btain the 
cially since 
eel. 

Simply pass in a reference of your window to the sf : : Mouse : : getPosition ( ) 
method. That's all you need. 

Summary 

e many 

things that can mean the difference between you happily developing an application 
ith proper 
and fl yet 

another step towards building an application that will not bite the dust simply 
because it was painful to work with due to its myopic construction. 

h this 
1 that we 
ries between 
ested itself 

into something completely different than it was before. None of that is certain to the 

rest of us, but it doesn't really matter. What matters is that we are in full control of 

us. And 

begin 

over 

control of 
me your 

journey, by learning about application states. We'll see you there! 


[ 91 ] 





Can I Pause This? 
-Application States 

A piece of software like a video game is rarely as simple as the term suggests. Most 
eal with in 

such an application. Nowadays, an industry-standard product also includes a nice 
e player to 

tinker with in order to start playing the game, manage the different settings it offers, 
view the credits or quit the application. On top of that, the title of this chapter also 
suggests the possibility of putting your game on pause for a moment or two. In 
sand between 
using, and a 

product that offers the same level of control as most games on the market. To supply 
the backbone to such an idea, in this chapter we will be covering: 

• Implementing the state manager 

• Upgrading the event manager to handle different states 

• Creating different states for the introduction, main menu and game-play 
sections of our game 

• Providing the means to pause the game 

• Implementing state blending 

• Stringing the states together to create cohesive application flow 
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What is a state? 

and what 
pment 

material before, you probably came across the term state. It can mean different 
e many different 

layers of your game, like the main menu, the intro that plays before the menu is 

its own way 

developer's 

arate, 

hat if you 

n would be 

ansitioning 

between the two at appropriate times. 

The most simplistic approach 

Let's begin by illustrating the most common approach newcomers take in order to 
ame could have: 

enum class StateType{ 

Intro = 1, MainMenu, Game, Paused, GameOver, Credits 

} ; 


Good start. Now let's put it to work by simply using a switch statement: 

void Game :: Update () { 
switch (m_state) { 

case (StateType : : Intro) : 

Updatelntro ( ) ; 
break ; 

case (StateType : :Game) : 

UpdateGame ( ) ; 
break ; 

case (StateType : :MainMenu) : 

UpdateMenu ( ) ; 
break ; 

} 

} 
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The same goes for drawing it on screen: 

void Game :: Render () { 
switch (m_state) { 

case (StateType : : Intro) : 

Drawlntro ( ) ; 
break ; 

case (StateType : :Game) : 

DrawGame ( ) ; 
break ; 

case (StateType : :MainMenu) : 

DrawMenu ( ) ; 
break ; 

} 

} 

completely 

out of the question. First of all, the switch statements are going to continue to grow 
when more states are added. Assuming we keep the functionality for updating and 
rendering a specific state localized to just one method, the number of these methods 
m being used 

for updating and another for rendering. Keep in mind, that's the minimal amount of 
events for 

each state individually or perform some kind of additional logic like late updating, 
d four extra 

methods that have to be implemented and added to the branches. 

ender two 
s. It is possible 

to still somehow string that functionality together by tying up a bunch of flags or 
creating combination states as follows: 

enum StateType { 

Intro = 1, Intro_MainMenu, MainMenu, Game, MainMenu_Game 
Paused, GameOver, MainMenu_GameOver , Credits, MainMenu_Credits 

// Crying in the corner. 

} ; 

This just keeps getting messier by the minute, and we haven't even got to expand our 
we want! 
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If you still aren't thinking about migrating to a different tactic by now, consider this 
one fipossible 
it of a 

problem on your hands from the point of efficiency. You may dynamically allocate 

use anymore 

lready 

classes, 

why not do it better? 

Introducing the state pattern 

All of the problems mentioned previously can be avoided after some careful 
of different 

game states simply being localized to their own classes. All of these classes will share 
the same methods for being updated and rendered, which makes inheritance the 
word of the hour. Let's take a look at our base state header: 

class StateManager; 

class BaseState{ 

friend class StateManager; 
public : 

BaseState (StateManager* l_stateManager ) 

: m_stateMgr (l_stateManager) , m_transparent ( false) , 
m_transcendent (false) { } 
virtual -BaseState (){ } 

virtual void OnCreateO = 0; 
virtual void OnDestroyO = 0; 

virtual void Activate () = 0; 
virtual void Deactivate () = 0; 

virtual void Update(const sf::Time& l_time) = 0; 
virtual void Draw() = 0; 

void SetTransparent ( const bool& l_transparent) { 
m_transparent = l_transparent ; 

} 

bool IsTransparent () const { return m_transparent ; } 
void SetTranscendent (const bool& l_transcendence) { 
m_transcendent = l_transcendence ; 

} 
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bool IsTranscendent () const { return m_transcendent ; } 
StateManager* GetStateManager ( ) { return m_stateMgr; } 
protected: 

StateManager* m_stateMgr; 
bool m_transparent ; 
bool m_transcendent ; 

} ; 


First, you'll notice we're using a forward declaration of the StateManager class. The 
manager 

will be implemented, only that it needs to keep a pointer to it. This is also done in 
order to avoid recursive definitions, because the StateManager class header needs 
to include the BaseState class header. 

es, we 

make them purely virtual, which means that the class inheriting from BaseState 
compile. 

The methods that any derived class has to implement consist of OnCreate and 
OnDestroy, which get invoked when the state is created and pushed on the stack, 
and later removed from the stack. Activate and Deactivate, which are called once 
from the top 

position, and lastly. Update and Draw, which are used for updating the state and 
drawing its contents. 

One last thing to note about this class is that it has a pair of flags: m_transparent 
and m_transcendent. These flags indicate if this state also needs to render or update 
erations of 
ut any 

additional expansion. 

Defining common types 

One thing that we're definitely going to keep from the previous example is the 
enumeration table of the state types: 

enum class StateType{ 

Intro = 1, MainMenu, Game, Paused, GameOver, Credits 

} ; 


Having the state types enumerated is convenient and it helps with automating the 
state creation, as you will see later on. 
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e using 
pointer 

to some of our most commonly used classes or "devices." Because there's more than 
one, it's quite useful to define a simple structure that will keep around pointers to 
the main window class and the event manager: 

struct SharedContext { 

SharedContext ( ) : m_wind (nullptr ) , m_eventManager (nullptr ) {} 

Window* m_wind; 

EventManager* m_eventManager ; 

} ; 


ation 

ocation, 

sound and networking. 

The state manager class 

Now that we have our helper structures set up, let's actually define the types that 
we will be 

using type definitions, the beauty of which is the fact that they reduce the amount of 
code you have to change in a case of modifying something about the type definition. 
Let's take a look at the state container type first: 

using StateContainer = std::vector< 
std : :pair<StateType, BaseState* >> ; 

e type and 

a pointer to a BaseState type object. You might be wondering why a map isn't a 

wever, 

ntainer, 

which is important if we want our state manager to work correctly. 

One of the design decisions in the state manager class also requires a container of 
state types, so let's define that: 

using TypeContainer = std : : vector<StateType> ; 

As you can see, it's simply a vector of the stateType enumeration types. 

The last type we need to define is a container for custom functions that will serve 
rom the 

BaseState class: 

using StateFactory = std : : unordered_map< 

StateType, std: : function<BaseState* (void) >> ; 
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We're using an unordered map here in order to map a specific state type to a specific 
function that will generate that type. If that sounds confusing now, be patient. It will 
be covered more thoroughly when we actually use it. 

Defining the state manager class 

er for the 

state manager class are now present, so let's write it: 

class StateManager { 
public : 

StateManager (SharedContext* l_shared) ; 

-StateManager ( ) ; 

void Update(const sf::Time& l_time) ; 
void Draw ( ) ; 

void ProcessRequests () ; 

SharedContext* GetContext ( ) ; 

bool HasState (const StateTypek l_type) ; 

void SwitchTo (const StateTypek l_type) ; 
void Remove (const StateTypek l_type) ; 
private : 

/ / Methods . 

void CreateState (const StateType& l_type) ; 
void RemoveState (const StateType& l_type) ; 

template<class T> 

void RegisterState (const StateType& l_type) { . . . } 

/ / Members . 

SharedContext* m_shared; 

StateContainer m_states; 

TypeContainer m_toRemove; 

StateFactory m_stateFactory ; 

} ; 


The constructor takes in a pointer to the SharedContext type we talked about 
earlier, which will be created in our main Game class. Predictably enough, the 
state manager also employs the use of Update and Draw methods, because it will 
be operated by the Game class, and it's nice to keep the interface familiar. For 
well as 

determining if it currently has a certain state on the stack. 


[ 99 ] 



Can I Pause This? - Application States 


Concluding the public methods, we have SwitchTo, which takes in a state type 


for removing a state from the state stack by its type. 


Remove, 


If you looked at the class definition from top to bottom, you may have noticed that 
we have a TypeContainer member called m_toRemove. In order to ensure smooth 
om the state 

container at any time. A simple solution here is keeping track of the state types we 
which 

is what the ProcessRequests method does. It is called last in the game loop, which 
ensures that the states in the m_toRemove container are no longer in use. 

Let's continue with the more advanced private methods and implementation of our 
state manager class in the next section. 


Implementing the state manager 

e heap, we 

must have some way of defining how they're created. The m_stateFactory member 
is a map that links a state type to a std : : function type, which we can be set to hold 
a body of a function through use of the lambda expression: 

template<class T> 

void RegisterState (const StateTypek l_type) { 

m_stateFactory [l_type] = [this] () -> BaseState* 

{ 

return new T(this) ; 

} ; 

} 

The code above maps the type l_type in the m_stateFactory map to a function 
plates 

here in order to reduce the amount of code. Because each state requires a pointer to 
the stateManager class in its constructor, we pass the this pointer in. We can now 
register different states like so: 

StateManager: : StateManager (SharedContext* l_shared) 

: m_shared ( l_shared) 

{ 

RegisterState<State_Intro> (StateType : : Intro) ; 
RegisterState<State_MainMenu> (StateType : :MainMenu) ; 
RegisterState<State_Game> (StateType : :Game) ; 
RegisterState<State_Paused> (StateType : : Paused) ; 

} 
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look at the 
destructor: 

StateManager : : -StateManager ( ) { 
for (auto &itr : m_states) { 
itr . second- >OnDestroy ( ) ; 
delete itr. second; 

} 

} 

Because we localize all the dynamic memory allocation of any states to this class, it's 
imperative that we also free the memory appropriately. Iterating over all the states 
s just that. 

Next, let's take a look at how to implement the draw method: 

void StateManager :: Draw () { 

if (m_states . empty ()) { return; } 
if (m_states . back ( ) . second- >IsTransparent ( ) 

&& m_states . size ( ) > 1) 

{ 

auto itr = m_states . end ( ) ; 
while (itr != m_states . begin ()) { 
if (itr ! = m_states . end ( ) ) { 

if ( ! itr- >second- >IsTransparent ( ) ) { 
break ; 

} 

} 

- -itr; 

} 

for (; itr != m_states . end ( ) ; ++itr) { 
itr- >second- >Draw ( ) ; 

} 

} else { 

m_states . back ( ) . second- >Draw ( ) ; 

} 

} 

First, just like the Update method, we check if the state container has at least one 
state. If it does, we check the most recently added one's transparency flag, as well 
cy would be 
isn't transparent, 

we simply invoke its Draw method. Otherwise, things get a little bit more interesting. 
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ective Draw 

on screen last. 

To do that, it's necessary to iterate through the state vector backwards until a state is 
found that is either not transparent or is the first state on the stack, which is what 
the while loop does. After such state is found, the Draw calls of all states from and 
including the one found, up to the very last one are invoked in the for loop. This 
effectively renders multiple states at once in correct order. 

A fairly similar procedure is followed when updating states: 

void StateManager :: Update ( const sf::Time& l_time) { 
if (m_states . empty ()) { return; } 
if (m_states . back ( ) . second- >IsTranscendent ( ) 

&& m_states . size ( ) > 1) 

{ 

auto itr = m_states . end ( ) ; 
while (itr != m_states . begin ()) { 
if (itr != m_states . end ( ) ) { 

if ( ! itr- >second- >IsTranscendent ( ) ) { 
break ; 

} 

} 

--itr; 

} 

for (; itr != m_states . end ( ) ; ++itr) { 
itr- >second- >Update (l_time) ; 

} 

} else { 

m_states .back () . second- >Update ( l_time) ; 

} 

} 

The state's transcendence flag is checked first, in order to determine whether the 
get updated 

then have their Update methods invoked with the elapsed time passed in as the 
argument, more commonly known as delta time. 

As always, we need to define some helper methods for a class to be truly flexible 
and useful: 

SharedContext* StateManager :: GetContext () { return m_shared; } 

bool StateManager : :HasState (const StateTypek l_type) { 
for (auto itr = m_states . begin () ; 
itr != m_states . end ( ) ; ++itr) 
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{ 

if (itr->first == l_type) { 

auto removed = std :: find (m_toRemove . begin () , 
m_toRemove . end ( ) , l_type) ; 
if (removed == m_toRemove . end ( ) ) { return true; } 
return false; 


return false; 

} 


The first method of obtaining the context is pretty straightforward. All it does is 
return a pointer to the m shared member. The second method simply iterates over 
the m_states container until it finds a state with the type l_type and returns true. 
If it doesn't fi 

returns false. This gives us a way to check if a certain state is on the stack, 
dding one. 

Let's implement the public method Remove: 

void StateManager: : Remove (const StateTypek l_type) { 
m_toRemove .push_back (l_type) ; 

} 


This method pushes back a state type into the m_toRemove vector for later removal, 
which is then processed by this method: 

void StateManager: : ProcessRequests ( ) { 

while (m_toRemove . begin ( ) != m_toRemove . end ( ) ) { 

RemoveState ( *m_toRemove . begin ( ) ) ; 
m_toRemove . erase (m_toRemove . begin ( ) ) ; 

} 

} 

The last method of this class that ever gets called, ProcessRequests, simply iterates 
over the m_toRemove vector and invokes a private method RemoveState which 
, ensuring 

the container is cleared, 
is what 

the SwitchTo method takes care of: 

void StateManager :: SwitchTo (const StateTypek l_type) { 
m_shared- >m_eventManager- >SetCurrentState (l_type) ; 
for (auto itr = m_states . begin () ; 
itr != m_states . end ( ) ; ++itr) 
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{ 

if (itr->first == l_type) { 

m_states .back ( ) . second- deactivate ( ) ; 

StateType tmp_type = itr->first; 

BaseState* tmp_state = itr->second; 
m_states . erase (itr) ; 

m_states . emplace_back (tmp_type, tmp_state) ; 

tmp_state- >Activate ( ) ; 

return; 

} 

} 

// State with l_type wasn't found. 

if ( !m_states . empty ()) { m_states . back (). second- deactivate () ; } 

CreateState (l_type) ; 

m_states .back ( ) . second- >Activate ( ) ; 

} 

ed context 

and call a method SetCurrentState. We haven't yet gotten around to adding it, 
however it will be covered shortly. What it does is it simply modifies an internal data 
game is in. 

Next, we must find the state with the type we want to switch to, so we iterate over 
the state vector. If we have a match, the current state that's about to be pushed back 
has its Deactivate method called to perform whatever functionality it has to, in 
temporary 

variables to hold the state type and the pointer to a state object, so we don't lose that 
tor by 

calling erase. After doing that, all the iterators to the state container are invalidated, 
the desired 
nd passing 

in our temporary variables. Then, we call the Activate method of the state that just 
t time. 

If the state with l_type isn't found, creating one is necessary. First, however, it's 
important to check if there's at least one state for which to call the Deactivate 
method, and call it, if there is one. After invoking a private method CreateState 
and passing in the state type, we grab the element from the state vector that was 
added most recently by CreateState, and call Activate. 
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It's time to see what exactly goes into creating a state: 

void StateManager :: CreateState (const StateType& l_type) { 
auto newState = m_stateFactory. find (l_type) ; 
if (newState == m_stateFactory . end ( ) ) { return; } 

BaseState* state = newState->second(); 
m_states . emplace_back (l_type, state) ; 
state- >OnCreate () ; 

} 

tor returned 

by the end ( ) method of std : : unordered_map, allowing us to make sure a state 
with such type can be created. If it can, a pointer of type BaseState, called state is 
ting invoked as a 

function, which if you remember was the std : : function type and returns a pointer 
ned "factory" 

to work. After retrieving a pointer to the newly allocated memory for a state, we 
simply push it back onto the state vector and call OnCreate for the state to do its 
internal logic regarding being freshly created. 

How do we go about removing a state? Let's take a look: 

void StateManager :: RemoveState (const StateType& l_type) { 
for (auto itr = m_states . begin () ; 
itr != m_states . end ( ) ; ++itr) 

{ 

if (itr->first == l_type) { 
itr- >second- >OnDestroy ( ) ; 
delete itr->second; 
m_states . erase (itr) ; 
return; 

} 

} 

} 

As always when dealing with std : : vector types, we iterate over it until a match 
is found. Removing the actual state begins by calling the OnDestroy method of said 
be ready for 

removal. Then we simply de-allocate the memory by using the delete keyword, 
method. 
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Improving the Event Manager class 

ate situations 

where the same key or event will be needed by at least two of the states. Let's say 
t's all 

fine, but what if the game-play state also registers the use of arrow keys and sets 

all states 

orse, 

n memory, 

especially since nobody likes application crashes. A simple way of dealing with this 
problem is grouping the callbacks together by state and only invoking them if the 
current state is that of a callback. This obviously means some re-definition of the 
types being dealt with: 

using CallbackContainer = std: : unordered_map< 

std : : string, std: : functioncvoid (EventDe tails* ) >> ; 
enum class StateType; 

using Callbacks = std: : unordered_map< 

StateType, CallbackContainer> ; 

Things are getting a little bit more complicated now. What used to be the Callback 
definition is now renamed CallbackContainer. We only want one of those per state, 
so it means having to use another map, which is where the new Callback definition 
comes in. It maps a state type to a CallbackContainer type, so that we can have 
only one CallbackContainer per state in addition to only one callback function 
per name. 

Despite these changes, the declaration for m_callbacks in the event manager header 
remains the same: 

Callbacks m_callbacks; 

There is one minor addition to the class data member list, and that is the current state: 

StateType m_currentState ; 
izing 

callbacks. Let's adapt the AddCallback method to these changes: 
template<class T> 

bool AddCallback (StateType l_state, const std::string& l_name, 
void (T : : *l_func) (EventDetails* ) , T* l_instance) 

{ 

auto itr = m_callbacks . emplace ( 

l_state, CallbackContainer () ) .first; 
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auto temp = std : : bind ( l_func , l_instance, 
std: : placeholders : :_1) ; 

return itr- >second . emplace ( l_name , temp) . second; 

} 

The first thing to note is that we have a new argument l_state in the method's 
footprint. Next, we attempt to insert a new element to the m callbacks map, pairing 
together the state argument and a new CallbackContainer. Since a map can only 
have one element with a specific index, in this case it's the state type, the emplace 
method always returns a pair of elements, the first of which is an iterator. If the 
reated. On the 

other hand, if an element with a specified index already existed, the iterator points to 
at iterator no 

matter what, and if there is no element with the index we specified, we're going to 
want to insert one. 

he actual 

callback into the CallbackContainer type, which is the second value in the pair that 
makes up the m_callbacks elements. The second value of a pair that gets returned 
f an insertion, 

and that's what gets returned for error checking. 

Now let's take a look at revising the removal of callbacks: 

bool RemoveCallback (StateType l_state, const std : : string& l_name) { 
auto itr = m_callbacks . f ind (l_state) ; 
if (itr == m_callbacks . end ( ) ) { return false; } 
auto itr2 = itr->second. f ind (l__name) ; 
if (itr2 == itr- >second . end ( ) ) { return false; } 
itr->second. erase (l_name) ; 
return true; 

} 

This one's fairly simple. All we do is use the find method twice instead of once. First, 
we find the state pair in the first map, then we erase the actual callback by its name 
in the second map, just like before. 

The last part of making this work just the way we want is fixing the way callback 
functions are actually called. Due to the type definitions that got changed, the way 
we invoke callbacks is also slightly different: 

void EventManager :: Update () { 

if (bind- >m_events . size ( ) == bind->c) { 

auto stateCallbacks = m_callbacks . f ind (m_currentState) ; 
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auto otherCallbacks = m_callbacks . f ind (StateType ( 0 ) ) ; 

if (stateCallbacks != m_callbacks . end ( ) ) { 

auto callltr = stateCallbacks->second. f ind (bind->m_name) ; 
if (callltr != stateCallbacks->second. end ( ) ) { 

// Pass in information about events. 
callItr->second ( &bind- >m_details ) ; 

} 

} 


if (otherCallbacks != m_callbacks . end ( ) ) { 

auto callltr = otherCallbacks->second. f ind (bind->m_name) ; 
if (callltr != otherCallbacks->second. end ( ) ) { 

// Pass in information about events. 
callItr->second ( &bind- >m_details ) ; 

} 

} 


} 

get checked 

now, not just one: stateCallbacks and otherCallbacks. The former is quite 
obvious, we're simply using find to obtain the map of all callbacks for the current 
state. The latter, however, passes in a state type value of o, which isn't a valid state 
type, since the enumeration starts at i. This is done because even in the case of 
cks for the 

window class, as well as other classes that extend beyond the scope of simple states 
and persist all the way throughout the life of an application. Anything with the state 
type 0 will be invoked regardless of which state we're in. 

The rest is fairly straightforward. Just like before, we're using the find method of 
the second value in the iterator that gets returned from the first search, which is 


One last thing we want to do here is modify the keys . cfg file to hold some extra 
keys for us in order to use them later: 


Window_close 0 : 0 
Fullscreen_toggle 5:89 
Intro_Continue 5:57 
Mouse_Left 9:0 
Key_Escape 5:36 
Key_P 5:15 
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The I nt ro_Cont inue binding represents a Spacebar "key down" event, Mouse_Left 
is the mouse left click event, Key_Escape is bound to the ESC "key down" event, and 
lastly, Key_p represents the letter P "key down" event. 

Incorporating the state manager 

While it's not quite time for fanfare, excitement is definitely in order because we 
can finally put our brand new stateManager class to work! The Game class header 
modification is a good start: 


#include " StateManager . h" 

class Game{ 
public : 

void LateUpdate ( ) ; 
private : 

StateManager m_stateManager ; 

} ; 

Sticking a new data member to the Game class and adding a new method for late 
's adjust 

the Game constructor to initialize the state manager: 

Game :: Game () : m_window ( "Chapter 5", sf : : Vector2u (800 , 600)), 
m_stateManager ( &m_context ) 

{ 


m_context . m_wind = &m_window; 

m_context . m_eventManager = m_window . GetEventManager ( ) ; 
m_stateManager . SwitchTo (StateType : : Intro) ; 

} 

Naturally, the first thing we do is create the context that will be used by all of the 
states and pass it into the constructor of the state manager. We then begin the 
e time 

switch to other states and force the flow of the application. 
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Lastly, let's adjust the three most important methods of the Game class: 

void Game :: Update () { 
m_window . Update ( ) ; 

ms tateManager . Update (m_elapsed) ; 

} 

void Game :: Render () { 

m_window . BeginDraw ( ) ; 

m s tateManager . Draw ( ) ; 

m_window . EndDraw ( ) ; 

} 

void Game : : LateUpdate ( ) { 

ms tateManager . ProcessRequests ( ) ; 

RestartClock ( ) ; 

} 

That's about as straightforward as it can be. One thing to note is that the RestartClock 
method is now called by the LateUpdate, which means we have to adjust the 
main . cpp file as follows: 

# inc lude " Game . h " 

void main(int argc, void** argv[]){ 

// Program entry point. 

Game game ; 

while ( ! game . GetWindow ( ) - >IsDone ( ) ) { 
game .Update () ; 
game . Render ( ) ; 
game . LateUpdate ( ) ; 

} 

} 


tion 

should give you a very impressive black screen. Hoorah! Let's actually create 
is. 

Creating the intro state 

It seems rather fitting to start with the intro state, in turn giving the state manager a 
t is with the 

header file, so let's get going: 

class State_Intro : public BaseStatef 
public : 
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void Continue (EventDetails* l_details) ; 
private : 

sf : : Texture m_introTexture ; 
sf : : Sprite m_introSprite ; 
sf : : Text m_text ; 
float m_timePassed; 

} ; 


The State_Intro 

the BaseState class. All of the purely virtual methods of the base class have to be 
implemented here. In addition to that, we have a unique method named Continue 
ly enough, 

we will be rendering a sprite on screen, as well as some text. The floating point data 
have 

spent in this state, in order to present the user with the ability to hit the Spacebar 
key after a certain interval to proceed into the main menu. The Continue method 
is responsible for handling that transition. 

Implementing the intro state 

We are getting close to finishing our first functional state! All that needs to be 
header 

file, and we're golden. Let's begin by including the header file of our class in 
State_Intro . cpp: 

#include " State_Intro . h" 

#include " StateManager . h" 

Note the second line. Because the StateManager class is forwardly declared in the 
BaseState header, we must include the state manager header in the implementation 
fie. 

We will never use constructors and destructors of our states to initialize or allocate 
anything and instead rely on the OnCreate and OnDestroy methods in order to 
retain maximum control of when the resource allocation and de-allocation actually 
happens: 

void State_Intro :: OnCreate () { 
m_timePassed = O.Of; 


sf::Vector2u windowSize = m_stateMgr- >GetContext ( ) - > 
m_wind- >GetRenderWindow ( ) ->getSize() ; 


m_introTexture . loadFromFile ( " intro . png" ) ; 
m_introSprite . setTexture (m_introTexture) ; 
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m_introSprite . setOrigin (m_introTexture . getSize ( ) . x / 2. Of, 
m_introTexture . getSize ( ) . y / 2. Of); 

m_introSprite . setPosition (windowSize . x / 2. Of, 0) ; 

m_font . loadFromFile ( "arial . ttf " ) ; 
m_text . setFont (m_font) ; 

m_text . setstring ( { "Press SPACE to continue" }); 
m_text . setCharacterSize (15) ; 

sf : : FloatRect textRect = m_text . getLocalBounds ( ) ; 
m_text . setOrigin (textRect . left + textRect . width / 2. Of, 
textRect . top + textRect . height / 2. Of); 
m_text . setPosition (windowSize . x / 2. Of, windowSize. y / 2. Of); 

EventManager* evMgr = m_stateMgr-> 

GetContext ( ) - >m_eventManager ; 
evMgr- >AddCallback (StateType : :Intro, " Intro_Continue" , 
&State_Intro : : Continue , this ) ; 

} 


o us at this 

point. First, we must initialize our data member m_timePassed to zero. Next, we 
obtain the shared context through the use of the state manager pointer from the 
base class, and use it to obtain the current window size. 

In order to position the m_text right in the middle of the screen, we set its origin to 
be the absolute center first, which is done by first obtaining a sf : : FloatRect data 
type by calling the getLocalBounds method of our sf : : text object. The left and top 
values of the sf: :FloatRect represent the top left corner of the text, which can be 



that 

the sf : : text object is using, the origin has to be re-calculated, because 


The basic idea of this intro state is to have a sprite come down from the top of the 
screen to the middle. After five seconds have passed, some text will appear underneath 
the sprite notifying the user that they can hit the Spacebar in order to proceed to the 
main menu. This is the texture we will be using for the descending sprite: 
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The last thing we need to do is to bind the Spacebar key to the Continue method 
of our intro class. We do that by obtaining the event manager instance through the 
shared context and setting up the callback, pretty much as we did in the previous 
chapter, except this time we need an additional argument: the state type. 

it removes its 

callback when removed, which can be done here: 

void State_Intro : : OnDestroy ( ) { 

EventManager* evMgr = m_stateMgr-> 

GetContext ( ) - >m_eventManager ; 
evMgr- >RemoveCallback (StateType : :Intro, " Intro_Continue " ) ; 

} 

Just like the AddCallback method, removal of callbacks also requires a state type as 
its first argument. 

ill be 

necessary: 

void State_Intro : :Update (const sf::Time& l_time) { 

if (m_timePassed < 5.0f){ // Less than five seconds. 
m_timePassed += l_time . asSeconds ( ) ; 

m_introSprite . set Posit ion (m_introSprite . get Posit ion ( ) . x, 

m_introSprite . getPosition ( ) . y + (48 * l_time . asSeconds ( ) ) ) ; 

} 

} 

Seeing how it's only desired for the sprite to be moving until it reaches the middle, a 
five second window is defined. If the total time passed is less than that, we add the 
delta time argument to it for the next iteration and move the sprite by a set number of 
pixels per second in the y direction, while keeping x the same. This guarantees vertical 
movement, which is, of course, completely useless, unless we draw everything: 

void State_Intro : : Draw ( ) { 

sf : : RenderWindow* window = m_stateMgr-> 

GetContext ( ) - >m_wind- >GetRenderWindow ( ) ; 
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window- >draw (m_introSprite) ; 
if (m_timePassed >= 5.0f){ 
window- >draw (m text ) ; 



After obtaining a pointer to a window through the shared context, we draw the 
sprite on screen. If more than five seconds have passed, we also draw the text, which 
notifies the player about the possibility of continuing past the intro state, the final 
piece of the puzzle: 

void State_Intro :: Continue () { 
if (m_timePassed >= 5.0f){ 

m_stateMgr- >SwitchTo (StateType : :MainMenu) ; 
m_stateMgr- >Remove (StateType : : Intro) ; 

} 

} 

te. The 

actual switching happens when the SwitchTo method is called. Because we won't 
he next line. 

ement 

empty versions of them, like so: 

void State_Intro :: Activate (){ } 
void State_Intro :: Deactivate (){ } 

Now it's time to sound the fanfares! Our first state's done and is ready for use. 
like this: 
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he screen and 

displays the message about continuing underneath after five seconds. Upon hitting 
Spacebar you will find yourself in a black window because we haven't implemented 
the main menu state yet. 

From this point on, all the repetitive code will be left out. For complete source code, 
please take a look at the source files of this chapter. 


The main menu state 

The flow, 
one, albeit 

a very simplistic version, starting as always with the header file: 

class State_MainMenu : public BaseState{ 
public : 

void MouseClick (EventDetails* l_details) ; 


private : 


sf : : 

: Text m text ; 

sf : : 

:Vector2f m buttonSize; 

sf : : 

:Vector2f m buttonPos; 

unsigned int m buttonPadding; 

Sf : : 

: RectangleShape m rects[3] 

sf : : 

: Text m labels [3] ; 


} ; 

The unique method to this class is the MouseClick. Since we're dealing with a 
r private 
padding size 

variables for buttons, drawable rectangles for buttons and text variables for button 
labels. Let's throw it all together: 

void State_MainMenu : : OnCreate ( ) { 
m_f ont . loadFromFile ( " arial . ttf " ) ; 
m_text . setFont (m_font) ; 

m_text . setstring ( sf : : String ( "MAIN MENU : " ) ) ; 
m_text . setCharacterSize ( 18 ) ; 

sf : : FloatRect textRect = m_text . getLocalBounds ( ) ; 
m_text . setOrigin (textRect . lef t + textRect . width / 2. Of, 
textRect. top + textRect . height / 2. Of); 
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m_text . setPosition (400 , 100) ; 

m_buttonSize = sf : : Vector2f ( 300 . Of , 32 . Of ) ; 
m_buttonPos = sf : : Vector2f (400 , 200) ; 
m_buttonPadding =4; // 4px. 

std::string str [3]; 
str (0] = "PLAY"; 

Str [1] = "CREDITS"; 

str [2] = "EXIT"; 

for(int i = 0; i < 3; ++i) { 

sf::Vector2f buttonPosition (m_buttonPos . x, m_buttonPos . y + 
(i * (m_buttonSize . y + m_buttonPadding) ) ) ; 
m_rects [i] . setSize (m_buttonSize) ; 
m_rects [i] . set Fill Color (sf : : Color : : Red) ; 

m_rects [i] . setOrigin (m_buttonSize . x / 2. Of, 
m_buttonSize . y / 2. Of); 
m_rects [i] . setPosition (buttonPosition) ; 

m_labels [i] . setFont (m_font) ; 

m_labels [i] . setstring (sf : : String (str [i] ) ) ; 

m_labels[i] . setCharacterSize ( 12 ) ; 

sf : : FloatRect rect = m_labels [i] . getLocalBounds ( ) ; 
m_labels [i] . setOrigin (rect . left + rect. width / 2. Of, 
rect . top + rect. height / 2.0f); 

m_labels[i] . setPosition (buttonPosition) ; 

} 


EventManager* evMgr = m_stateMgr-> 

GetContext ( ) - >m_eventManager ; 
evMgr- >AddCallback (StateType : :MainMenu, "Mouse_Lef t " , 
&State_MainMenu : :MouseClick, this) ; 

} 


data members 
get defi. 
means a 

sophisticated GUI system. A more robust way of actually designing one will be 
covered in later chapters, however, this will suit our needs for now. 
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oned before: 

void State_MainMenu : :OnDestroy() { 

EventManager* evMgr = m__stateMgr- > 

GetContext ( ) - >m_eventManager ; 
evMgr - >RemoveCal lback (StateType : :MainMenu, "Mouse_Lef t " ) ; 

} 

Upon the state getting activated, we need to check if the main game-play state exists 
on the state stack in order to adjust the "play" button to instead say "resume": 

void State_MainMenu :: Activate () { 

if (m_stateMgr- >HasState (StateType : : Game) 

&& m_labels [0] .getStringO == "PLAY") 

{ 

m_labels [0] . setstring (sf : : String ( "RESUME" ) ) ; 
sf : : FloatRect rect = m_labels [0] . getLocalBounds ( ) ; 
m_labels[0] . setOrigin (rect . left + rect. width / 2. Of, 
rect. top + rect. height / 2. Of); 

} 

} 

he 

sf : : drawable object are now different. 

The Moused ick method can be implemented as follows: 

void State_MainMenu: :MouseClick (EventDetails* l_details) { 
sf::Vector2i mousePos = l_details- >m_mouse ; 

float halfX = m_buttonSize . x / 2. Of; 
float halfY = m_buttonSize . y / 2. Of; 
for(int i = 0; i < 3; ++i) { 

if (mousePos . x >= m_rects [i] . getPosition ( ) .x - halfX && 
mousePos. x <= m_rects [i] . getPosition ( ) .x + halfX && 
mousePos. y >= m_rects [i] . getPosition ( ) .y - halfY && 
mousePos. y <= m_rects [i] . getPosition (). y + halfY) 

{ 

if (i == 0 ) { 

m_stateMgr- >SwitchTo (StateType : :Game) ; 

} else if (i == 1 ) { 

// Credits state. 

} else if (i == 2 ) { 
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m_stateMgr- >GetContext ( ) - >m_wind- >Close ( ) ; 



, which gets 

passed in as the argument. Then we set up some local floating point type variables 
that will be used to check the boundaries of the buttons and begin looping over all 
the buttons. Because the origins of every button are set to the absolute middle, we 
sition is 
statement 

checks which ID has collided and performs an action accordingly. In the case of the 
"play" button being pressed, we switch to the game state. If the exit button is pressed, 
we invoke the Window : : Close method through the shared context. 

Finally, let's draw the main menu: 

void State_MainMenu : : Draw ( ) { 

sf : : RenderWindow* window = m_stateMgr- >GetContext ( ) - > 
m_wind- >GetRenderWindow ( ) ; 
window- >draw (m_text ) ; 
for(int i = 0; i < 3; ++i){ 
window- >draw (m_rects [i] ) ; 
window- >draw (m_labels [i] ) ; 

} 

} 

After obtaining the render window pointer through the shared context, drawing the 
abel. 

Upon successful compilation and execution, we're again presented with the intro 
screen. When hitting spacebar, a main menu opens, looking something like this: 


MAIN MENU: 

PLAY 

CREDITS 

EXIT 
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It's not the prettiest sight in the world, but it gets the job done. Clicking the PLAY 
button once again leaves us with a black screen, while hitting EXIT closes the 
application. Neat! 

A sample game state 

ting on the 
d states, 
re than 

suffice. We also need methods for switching to the menu state, as well as the paused 
state. Knowing that, let's bang out the header for the game-play state: 

class State_Game : public BaseStatej 
public : 

void MainMenu (EventDetails* l_details) ; 
void Pause (EventDetails* l_details) ; 
private : 

sf : : Texture m_texture; 
sf::Sprite m_sprite; 
sf::Vector2f m_increment; 

} ; 


data 

members in the OnCreate method: 

void State_Game :: OnCreate () { 

m_texture . loadFromFile ( "Mushroom . png" ) ; 
m_sprite . setTexture (m_texture) ; 
m_sprite . setPosition (0,0) ; 

m_increment = sf : : Vector2f (400 . Of , 400 . Of ) ; 

EventManager* evMgr = m_stateMgr-> 

GetContext () - >m_eventManager ; 
evMgr- >AddCallback (StateType : : Game , "Key_Escape" , 
&State_Game: : MainMenu, this) ; 
evMgr- >AddCallback (StateType : :Game, "Key_P", 
&State_Game: : Pause, this) ; 

} 
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After loading the texture and binding the sprite to it, we set up its position, 
defia two 
them upon 

destruction of the state, like so: 

void State_Game : : OnDestroy ( ) { 

EventManager* evMgr = m_stateMgr-> 

GetContext ( ) - >m_eventManager ; 
evMgr- >RemoveCallback (StateType : :GAME, "Key_Escape" ) ; 
evMgr- >RemoveCallback (StateType : :GAME, "Key_P") ; 

} 

The update method will hold the same code we've used previously: 

void State_Game :: Update (const sf::Time& l_time) { 

sf::Vector2u l_windSize = m_stateMgr- >GetContext ( ) - > 
m_wind- >GetWindowSize ( ) ; 
sf::Vector2u l_textSize = m_texture . getSize ( ) ; 

if ( (m_sprite . getPosition ( ) . x > l_windSize.x - 
l_textSize.x && m_increment . x >0) j 
(m_sprite . getPosition ( ) .x < 0 && m_increment . x < 0)) 

{ 

m_increment . x = -m increment . x; 

} 

if ( (m_sprite . getPosition (). y > l_windSize.y - 
l_textSize.y && m_increment . y >0) j 
(m_sprite . getPosition ( ) .y < 0 && m_increment . y < 0)) 

{ 

m_increment . y = -m increment . y; 

} 

m_sprite . setPosition (m_sprite . getPosition ( ) .x + 

(m_increment . x * l_time . asSeconds ( ) ) , 
m_sprite . getPosition () .y + 

(m_increment . y * l_time . asSeconds ())) ; 

} 

ndaries, the 
position 
regular as 

clockwork. Let's draw the sprite on the screen: 

void State_Game : : Draw ( ) { 

m_stateMgr- >GetContext ( ) - >m_wind- > 

GetRenderWindow ( ) ->draw (m_sprite) ; 

} 
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Now let's implement the methods for switching states: 

void State_Game : :MainMenu (EventDetails* l_details) { 
m_stateMgr- >SwitchTo (StateType : :MAIN_MENU) ; 

} 


void State_Game :: Pause (EventDetails* ldetails) { 
m_stateMgr- >SwitchTo (StateType : : PAUSED) ; 

} 

Notice that the game state does not remove itself here, just like the main menu state. 
This means that it's still alive in memory and is waiting to be pushed back to the front 
of the vector to be updated and rendered again. This allows the user to pop back to the 
main menu and resume the game state at any time without losing progress. 

Running the application now will transition us through the intro state into the 
main menu. Hitting the PLAY button will leave us with a bouncing mushroom, 
just like before: 



h point 

you can choose to click the RESUME button to pop back into the game state, or the 
EXIT button to quit the application. There's just one more state left to implement to 
fully showcase the abilities of this system! 

The means to pause 

e as a 

way of putting the game on pause. While that's technically true, why not explore 
a second option, which looks much trendier than simply popping the main menu 
open? After writing so much code, we deserve a nice looking paused state: 

class State_Paused : public BaseStatej 
public : 


void Unpause (EventDetails* l_details) ; 
private : 
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sf : : Text m_text ; 

sf : : RectangleShape m_rect; 

} ; 

This one is quite simple. Once more, we define an additional method, in this case 
Unpaused 

in order to draw the text "PAUSED" on screen, as well as a nice semi-transparent 
backdrop, represented by the sf : : RectangleShape. Let's implement the OnCreate 
method for the last time in this chapter: 

void State_Paused :: OnCreate () { 

SetTransparent (true) ; // Set our transparency flag. 

m_f ont . loadFromFile ( " arial . ttf " ) ; 

m_text . setFont (m_font) ; 

m_text . setstring ( sf : : String ( " PAUSED" ) ) ; 

m_text . setCharacterSize ( 14 ) ; 

m_text . setStyle (sf : :Text : :Bold) ; 

sf::Vector2u windowSize = m stateMgr-> 

GetContext ( ) - >m_wind- >GetRenderWindow ( ) - >getSize ( ) ; 

sf : : FloatRect textRect = m_text . getLocalBounds ( ) ; 
m_text . setOrigin (textRect . lef t + textRect . width / 2. Of, 
textRect. top + textRect . height / 2. Of); 
m_text . setPosition (windowSize . x / 2. Of, windowSize. y / 2. Of); 

m_rect . setSize (sf : : Vector2f (windowSize) ) ; 
m_rect . setPosition (0,0) ; 

m_rect . set Fill Color (sf : : Color (0,0,0,150) ) ; 

EventManager* evMgr = m_stateMgr-> 

GetContext ( ) - >m_eventManager ; 
evMgr- >AddCallback (StateType : : Paused, "Key_P", 

&State_Paused : : Unpause , this ) ; 

} 

A distinct difference here is the use of m_transparent flag, which is a protected data 
member of the BaseState class. Setting it to true means we're allowing the state 

t its fill color 
s makes it 

nice and translucent while darkening everything that's behind it. 
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The fihe 

callback to the Unpause method. Upon destruction of this state, it needs to be 
removed like so: 

void State_Paused : : OnDestroy ( ) { 

EventManager* evMgr = m_stateMgr- > 

GetContext ( ) - >m_eventManager ; 
evMgr- >RemoveCallback (StateType : : Paused, "Key_P") ; 

} 

Now let's draw the rectangle and text we created: 

void State_Paused : : Draw ( ) { 

sf : : RenderWindow* wind = m_stateMgr-> 

GetContext () - >m_wind- >GetRenderWindow ( ) ; 
wind- >draw (m_rect ) ; 
wind- >draw (m_text ) ; 

} 

Also, let's implement the Unpause method by simply switching to the game-play 
state: 

void State_Paused :: Unpause (EventDetails* l_details) { 
m_stateMgr- >SwitchTo (StateType : :Game) ; 

} 


simply 

switching back to it is sufficient. 

Now, take a deep breath and compile the application again. Getting past the intro 
state, hitting the PLAY button in the main menu, and hitting the P key on your 
keyboard will effectively pause the game-play state and darken the screen subtly, 
while displaying the text PAUSED right in the middle, as shown here: 



finished 
t can 

barely be controlled. 
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Common mistakes 

e of 

ply draws 
d in the 

constructor of StateManager. 

The window not responding to the F5 key being pressed or the close button being 
hit is a sign of the global callbacks not being set up right. In order to make sure a 
callback is invoked no matter which state you're in, it must be set up with the state 
type of 0, like so: 

m_eventManager- >AddCallback (StateType ( 0 ) , " Fullscreen_toggle" , 

&Window: : ToggleFullscreen, this) ; 
m_eventManager- >AddCallback (StateType ( 0 ) , "Window_close " , 

&Window: : Close, this) ; 

menu state, 
e window. 

Obtaining coordinates through sf : : Mouse : : GetPosition is not going to do the 
same, unless a reference to a sf : : window class is provided as an argument. 

Summary 

r tool 

belt to fashion states that can be transparent, updated in groups, and supported 
gain, make it 

better, faster and implement different features that didn't get covered in this chapter. 
Expand it, crash it, fix it and learn from it. Nothing is ever good enough, so build 
onto the knowledge you've gained here. 

A famous Chinese proverb states: "Life is like a game of chess, changing 
with each move" . 

While that analogy holds true, life can also be like a game with states. Breaking it 
down into smaller and more manageable parts makes it a whole lot easier to handle. 
Great ideas come 
s chapter 

you are taking off with not only the knowledge of simply how to build yet another 
idea 
you in 

the next chapter! 
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Set It in Motion! - Animating 

and Moving around 

Your World 


Our first game, while functional, certainly wasn't that visually appealing, at least 
not for this century. First of all, the graphics barely represented what they were 
g that gave 
an older 
game like Snake, 

Super Mario 

Bros rely on the fact that the game world extends beyond the boundaries of your 
ty to build a 

larger game world that doesn't have to fit within a certain pre-designated rectangle. 
A simple decision to represent game characters with images instead of basic shapes, 
as well as providing the means for the screen to be moved opens up a lot of doors. 

In this chapter, we will be covering: 

• SFML views and screen scrolling 

• Automated resource management and handling 

• Creation and application of sprite-sheets 

• Sprite-sheet animation 

There's a lot to learn, so let's not waste any time and dive right in! 
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Use of copyrighted resources 

's due to the 

artists who created the textures, sprites, and other art we're going to be using for our 
game. These assets include: 

• Lemcraft by richtaur under CCO 1.0 license: http : //opengameart . org/ 
content/lemcraf t 

• Prototyping 2D Pixelart Tilesets by http : //www. robotality . com under 
CC-BY-SA 3.0 license: http : / /opengameart . org/content /prototyping - 
2d-pixelart- tilesets 

• Generic Platformer Tileset (16x16) + Background by etqws3 under CCO 1.0 
license: http : / /opengameart . org/content/generic-platf ormer- 
tileset- 16x1 6 -background 

• Knight and Rat sprites by backyardninja: http : / /www . dumbmanex . com/ 
bynd_f reestuf f . html 

The licensing of all the resources listed above allows for any use of the material, 
even commercial. For more information on the two specific licenses, please visit 
the following links: 

• http : / / creativecommons . org/publicdomain/ zero/ 1 . 0/ 

• http : // creativecommons . org/ licenses /by- sa/ 3.0/ 

Finding and using the current directory 

There's no doubt that after programming for a while, the inconveniences of reading 
or writing to files start to quickly build up. It may not be so bad when running 
in while 

debugging, because it is no longer relative to the directory where the executable 
is, but instead where the . obj files are located. For the rest of this book, we will be 
using a function to obtain the full path to your executable, regardless of where it is 
or how it's being launched. Let's take a look at a new header file that will contain 
this function, called utilities. h: 

#pragma once 

#def ine RUNNING_WINDOWS 

#include <iostream> 

#include <string> 

#include <algorithm> 

namespace Utils { 

#if def RUNNING WINDOWS 
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#def ine WIN32_LEAN_AND_MEAN 
#include <windows.h> 

#include <Shlwapi.h> 

inline std::string GetWorkingDirectory ( ) { 

HMODULE hModule = GetModuleHandle (nullptr) ; 
if (hModule) { 

char path [256] ; 

GetModuleFileName (hModule , path, sizeof (path) ) ; 

PathRemoveFileSpec (path) ; 
strcat_s (path, "\\") ; // new 
return std :: string (path) ; // new 

} 

return " " ; 

} 

#elif defined RUNN I N G_L I NUX 
#include <unistd.h> 

inline std:: string GetWorkingDirectory () { 
char cwd [1024] ; 

if (getcwd (cwd, sizeof (cwd) ) != nullptr) { 

return std :: string (cwd) + std :: string ("/") ; 

} 

return " " ; 

} 

#endif 

} 

#pragma once is widely supported, but is non-standard. It can be 
an older compiler. 

If a running_windows macro is set, it defines a method that first obtains the full path 
including the executable and its extension, then obtains only the name and extension 
of the executable and finally strips the full path of it before returning the string, 
ides in. These 

functions are specific to Windows and won't work on other operating systems, so 
this header needs to define the same method differently for each of them. 




Using these functions to obtain the current directory requires the 
Shlwapi . h header file to be included, as well as the shlwapi . lib file 
being listed in the linker's additional dependencies in all configurations. 
Forgetting to fulfill these requirements will cause linker errors. 
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As you can see, we have Windows and Linux operating systems covered here. It is 
if you 

want your application to run properly. 

Using the SFML views 

Up until this point, we have only dealt with code that renders things within the 
e we 

needed the screen to move yet, which would be fine if we lived in the early days of 
d. Take, for 

example. Super Mario Brothers, a classic side-scroller. Its genre alone pinpoints what 
our fimovement, 

resizing or rotation of the screen is desirable, using the sf : : view is necessary. 

What is sf : : view? It's a rectangle. That's it. If you have ever held your fingers in a 

a view with 

eyond 

the cut-off point of the window. If you're still not "getting the picture," here's an 
illustration to lead you in the right direction: 



The sf : : view is a very lightweight object that essentially holds a few floating point 
r can take in 

a sf : : FloatRect type, which defines a rectangular area of the screen, or it can take 
two sf : : Vector2 f types, the first one being the centre of the view and the second 
one being the size: 

// Top-left corner at 500:500, bottom-right at 1000:1000. 
sf : :View f irst (sf : : FloatRect (500,500,1000,1000)) ; 

// Center at 250:250, size is 800:600. 

sf : : View second (sf : :Vector2f (250 , 250) , sf :: Vector2f (800,600)); 
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As you can see, views are mostly manipulated by their centre instead of their top-left 
corner, unlike most of the other shapes. 

Moving the view can be done by manipulating its centre, like so: 

// Top-left corner at 0:0, bottom-right at 800:600. 

sf : : View view (sf : : FloatRect (0,0,800,600)); 

view. setCenter (100 , 100) ; // Move center to 100:100. 

It can also be moved by an offset, via the move method: 

view . move ( 100 , 100 ) ; // Move by 100x100 offset. 

Resizing the view can be accomplished by either using the setsize method or 
zooming by a factor, using the zoom method: 

view. setsize (640 , 480); // Creates a smaller view space, 
view . zoom ( 0 . 5f ) ; // Also creates a smaller view space. 

In the fi 

case applies a factor of 0 . 5f to its current size, which cuts it down in half, making 
everything on screen larger. 

In order to use a specific view, you must call the setview method of the window 
instance you're using: 

window . setview (view) ; // Applies view to window. 



The setview method does not take values in by reference. It simply 

the view is altered at any point in your code, you must call the setview 
method again in order to apply those changes and make them reflect. 


One last thing worthy of mentioning is that two views can be obtained from the 
window object as well. The first kind of view is the current one being used, and the 
second view is the default a window starts with. It's the same size as the window 
se views can be 
done like so: 

sf::View view = window . getView () ; 

sf : : View defaultView = window . getDef aultView ( ) ; 
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Preparing application states for views 

In order to add support for panning around our world, we must adjust the state 

g like 

the 

aracter 

each 

t by modifying 
the BaseState . h file: 

class BaseState{ 
public : 


sf::View& GetView(){ return m_view; } 
protected: 


sf : :View m_view; 

} ; 

the 

e. All we've 

added is a view data member and a method for obtaining it. Let's move on to 
putting this view to work in our state manager: 

void StateManager :: CreateState (const StateType& l_type) { 

BaseState* state = newState- >second ( ) ; 

state- >m_view = m shared- >m_wind- > 

GetRenderWindow ( ) - >getDef aultView ( ) ; 


Because we don't want the default constructor of sf : : view to initialize our view 
creating 

iew never moves, 

which is why it's set to default first. If a state wishes to define its own view, it can 
always do so in the OnCreate method, as you will see shortly. Let's move on to 
state switching: 

void StateManager :: SwitchTo ( const StateTypek l_type) { 

for (...) 

{ 

if (itr->f irst == l_type) { 
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m_shared- >m_wind- >GetRenderWindow ( ) - > 
setview ( tmp_state- >GetView ( ) ) ; 

return; 



m_states . back ( ) . second- >Activate ( ) ; 

m shared- >m_wind- >GetRenderWindow ( ) - >setview ( 
m_states . back ( ) . second- >GetView ( ) ) ; 

} 


want to change 
hat's not 

accomplished and the game state moves the view, switching to another state will 
re rendered 

outside the window's view space, 
ent views 

are introduced. This can be a little bit difficult to understand, so let's illustrate the 
d state is 

transparent, it needs to draw the state before it first, in order to blend them together, 
ents in 

window coordinates and it never needs the view to move. If the view of the window 
ew space and 

will therefore be either partially visible or not there at all. We could translate window 
coordinates to world coordinates and update positions of these elements each frame 
to "follow" the screen, but that's not an elegant or efficient solution. Therefore, we 
so: 

void StateManager : : Draw ( ) { 

for ( ; itr != m_states . end ( ) ; ++itr) { 

mshared- >m_wind- >GetRenderWindow ( ) - > 
setview (itr- >second- >GetView ( ) ) ; 

itr- >second- >Draw ( ) ; 

} 


} 
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ved. 

Consider the following illustration: 


i c 600, y: 700 


window. setView( view); window. setView(window. getOefaultView( ) ) ; 

window. draw(scene); window. draw(overlay); 


x:0,y:0 


HP: 10 MP 5 Time: 15s 


Objeclive: Don't die 1 


window . display ( ) ; 


HP 10 MP 5 Time 15s 


Objective: Don t die' 


the scene, 
iew of the window 

is then applied. This moves the window view space's top-left corner back to (0;0), 
which matches the local window coordinates. Because the elements that are about to 
window's 
nt parts 

are blended, while opaque pixels are overwritten. Finally, window . display ( ) ; gets 
called and the frame buffer is drawn on screen. The result is both the scene and the 
elements being blended together. 

is a new 

method in the Window class for obtaining a sf : : FloatRect type that defines the 
window view space: 

sf : : FloatRect Window: : GetViewSpace ( ) { 

sf::Vector2f viewCenter = m_window . getView ( ) . getCenter ( ) ; 
sf::Vector2f viewSize = m_window . getView (). getSize () ; 
sf::Vector2f viewSizeHalf (viewSize . x / 2, viewSize. y / 2); 
sf :: FloatRect viewSpace (viewCenter - viewSizeHalf, viewSize); 
return viewSpace; 

} 

Then it 
s of the view's 
e rectangle of the 
his will be 
useful later on. 
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Automated resource management 

Let's talk about textures and the way we've been using them so far. A texture in 

ory wise. 

elevant 

classes. A scenario that illustrates how horrendous this strategy is would be as 
doesn't seem 

like the type of thing that you could just brush off your shoulders, as it only happens 
once in a blue moon. Creating multiple textures that all hold the same data is a huge 
waste of resources, and adding methods for obtaining textures from the classes 
t, it would also 

mean that other classes would have to have access to the one that holds this texture. 
Nobody should subject themselves to such torture. 

of our 
d in order 
identifiers 
m a file that 

maps a name to a path. We can name it Textures . cfg and it would look something 
like this: 

Intro media/Textures/intro . png 
PlayerSprite media/Textures/PlayerSheet .png 
RatSprite media/Textures/RatSheet .png 
TileSheet media/Textures/tilesheet . png 
Bgl media/Textures/bgl . png 
Bg2 media/Textures/bg2 . png 
Bg3 media/Textures/bg3 . png 

This approach, of course, can be used for other types of resources, not just textures. 
Later on, we'll be working with fonts and sound files as well, so let's design an 
abstract base class that will take care of all the common tasks first, before delving 
into handling textures specifically. 

Designing a resource manager 

All of the resources we're going to be working with are going to be counted and 
le, it needs 

to be requested. If it's no longer needed, the resource is released. It sounds simple 
enough, so let's write it: 

template<typename Derived, typename T> 
class ResourceManager { 
public : 
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ResourceManager ( const std::string& l_pathsFile) { 
LoadPaths (l_pathsFile) ; 

} 


virtual -ResourceManager () { PurgeResources ( ) ; } 


private : 

std : : unordered_map<std : :string, 

std : : pair<T* , unsigned int>> m_resources; 
std :: unordered_map<std :: string, std::string> m_paths; 

} ; 


When dealing with classes that use templates, it's necessary for the implementation 
of the methods to be in the header file, because the compiler needs to have access to 
the implementation in order to instantiate the methods with the template arguments. 
With that being said, let's talk about the m_resources data member. It's using a map, 
which is going to tie a string handle to a pair of elements, the first of which is the 
template parameter of a resource and the second is an unsigned integer type that will 
be used as a counter for how many places are currently using this particular resource. 

hs. 

The constructor calls an internal method in order to load the paths from a specific 
and 

de-allocate all of its resources, 
lass, 

starting with the public ones: 

T* GetResource (const std :: strings l_id) { 
auto res = Find(l_id) ; 
return(res ? res->first : nullptr); 

} 

er. It uses 

nternal Find 

method that we'll define later. It returns a pointer to the pair element of the map if 
something is found, or nullptr if nothing is found. 

We also might be interested in retrieving one of the paths to a particular resource: 

std::string GetPath ( const std::string& l_id) { 
auto path = m_paths . f ind (l_id) ; 
return (path != m_paths . end ( ) ? path->second : 

} 
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This system would be useless without some way to guarantee that a resource doesn't 
let's implement 

a method that will register the use of a resource: 

bool RequireResource (const std : : strings l_id) { 
auto res = Find(l_id) ; 
if (res) { 

++res->second; 
return true; 

} 

auto path = m_paths . f ind ( 1 id ) ; 

if (path == m_paths . end ( ) ) { return false; } 

T* resource = Load (path- >second) ; 
if ( Iresource) { return false; } 

m_resources . emplace (l_id, std: :make_pair (resource, 1) ) ; 
return true; 

} 

This method serves two purposes. One is simply incrementing the counter of 
instances a resource is being used when it's required. The second purpose of it is 
er. It first looks 
match is found, 

it tries to acquire a pointer to newly allocated memory, which gets returned by the 
Load method. If it hasn't returned a nullptr value, the resource gets inserted with 
a counter set to l. 

Just like for every yin there must be a yang, for every resource required, there must 
be a point where it's no longer needed: 

bool ReleaseResource (const std : : string& l_id) { 
auto res = Find(l_id) ; 
if (Ires) { return false; } 

--res->second; 

if ( ! res- >second) { Unload (l_id) ; } 
return true; 

} 

This method tries to find a resource in the container using the string handle. If one 
is found, its use counter is decremented. If the counter is now at o, this resource is 
e Unload 

method. 
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At some point, everything must go. This is the purge method: 
void PurgeResources ( ) { 

while (m_resources . begin ( ) != m_resources . end ( ) ) { 

delete m_resources . begin ( ) - >second . first ; 
m_resources . erase (m_resources . begin ( ) ) ; 

} 

} 

e elements 
e container 

entry by passing in an iterator. 

Because of the unique nature of some resources, certain methods aren't universal, 
want, a 

Load method is going to be used in each derived manager. In order to avoid run-time 
polymorphism, a Curiously Recurring Template Pattern can be used like so: 

T* Load (const std :: strings l_path) { 

return static_cast<Derived* > ( this ) - >Load ( l_path) ; 

} 

Derived classes will implement their own versions of Load, but will not rely on 
resolving virtual pointers to functions during run-time. 

private 

methods that make this functionality possible, beginning with Find: 

std :: pair<T* , unsigned int>* Find(const std::string& l_id) { 
auto itr = m resources . find (l_id) ; 

return (itr != m_resources . end ( ) ? &itr- >second : nullptr); 

} 

al resource 
n argument 

isn't located in the resource container, nullptr is returned instead. 

Unloading a resource doesn't bring anything new to the table: 

bool Unload(const std::string& l_id) { 
auto itr = m resources . find (l_id) ; 
if (itr == m resources . end ()) { return false; } 
delete itr- >second . first ; 
m_resources . erase ( itr) ; 
return true; 

} 
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As always, we first look for the element in the container by the string handle. If it 
iner and 

return from the method. 

Lastly, we can't use those string handles without having paths that they map to. 

Let's load them in: 

void LoadPaths (const std :: strings l_pathFile) { 
std: : if stream paths; 

paths . open (Utils GetWorkingDirectory ( ) + l_pathFile) ; 
if (paths . is_open ( ) ) { 
std::string line; 
while ( std : : get line (paths , line) ) { 
std: : stringstream keystream ( line) ; 
std:: string pathName; 
std::string path; 
keystream >> pathName; 
keystream >> path; 
m_paths . emplace (pathName , path) ; 

} 

paths . close ( ) ; 
return; 

} 

std: : cerr << 

"! Failed loading the path file: " 

<< l_pathFile << std::endl; 

} 

If you know anything about loading in files in C++, this should raise no eyebrows. 
All it does is set up an input stream called paths. It then tries to open it, by passing 
in the full path to the file, thanks to our GetWorkingDirectory function that was 
mentioned earlier. If the file is open, it means it was found and can be read. A string 
type is defined for use as a way of holding the current line of the file as it reads them 
in the file 

we're parsing and passes in that new line to the line variable. A stringstream 
Two string 

variables are defined, one for the path identifier and one for the actual path. They 
get filled from the keystream variable by using its overloaded >> operator, which 
essentially just grabs everything in the line until it encounters a space delimiter. We 
then insert this information into the path container and close the file after the loop 
is over. 
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Implementing the texture manager 

texture 

loading in its own class. Because there's only one method that we want to implement, 
it might as well be done in the header file: 

class TextureManager : 

public ResourceManager<TextureManager , sf::Texture> 

{ 

public : 

TextureManager ( ) : ResourceManager (" textures . cfg" ){ } 

sf::Texture* Load(const std::string& l_path) { 
sf : : Texture* texture = new sf :: Texture () ; 
if ( ! texture->loadFromFile ( 

Utils :: GetWorkingDirectory ( ) + l_path) ) 

{ 

delete texture; 
texture = nullptr; 

std::cerr << "E Failed to load texture: " 

<< l_path << std::endl; 

} 

return texture ; 

} 

} ; 

We create the TextureManager class and inherit from ResourceManager in addition 
eals with for 

the template, which is, of course, a sf : : Texture. The constructor of the texture 
manager is only used to call the base class constructor in the initializer list to pass 
in the file name that contains the bindings of handles and paths. 

In the Load method, we allocate new memory for the texture and attempt to load it 
he allocated 

memory and print out a console message to notify the user of the failure. That is 
literally all there is to the texture manager class. Time to put it to work! 
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Introducing sprite sheets 

First, let's whet your appetite by looking into the future of using sprite sheets, which 
allow you to create animations that look like this: 



ally an 

image that can be moved around, cropped, scaled, and rotated just to mention a few 
ultiple sprites, 
ation is 

sheet, which is 

being accessed and cropped in order to represent a single sprite. This is what a small 
part of it looks like as a texture: 



the size 

constraints of a particular project, as well as the specifics of game-play. The format 
means the 
"perfect design." 
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Why would we want to use a sprite sheet? Well, the biggest advantage is that it 
makes accessing sprites easier and faster, not to mention less memory-consuming, 
textures of 
an be cropped. 

In certain cases, careful packing of a sprite sheet can save a lot of resources. If 
effis for each 

sprite definitely takes the cake. 

Implementing a sprite sheet class 

Because we want to be able to modify anything related to sprite sheets on the fly, 
loading them from a file makes the most sense. Let's start by taking a look at what 
the sprite sheet for a player might look like by making a Player . sheet file: 

Texture PlayerSprite 
Size 32 32 
Scale 1.0 1.0 

| Type | Name | StartFrame | EndFrame | Row | FrameTime | FrameActionStart | End | 


AnimationType Direct 

ional 


Animation 

Idle 

0 

7 

0 

0.2 -1 

-1 

Animation 

Walk 

0 

5 

2 

0.1 -1 

-1 

Animation 

Jump 

0 

3 

4 

0.2 -1 

-1 

Animation 

Attack 

0 

4 

6 0.08 

2 3 

Animation 

Hurt 

0 

2 

8 

0.2 -1 

-1 

Animation 

Death 

0 

8 

10 0.15 

-1 


It starts by specifying a handle of the texture that will be used. Some additional 
data about the sprite itself is also defined, such as the individual sprite size and 
scale. We then jump to a row that's commented out. It describes the order and 
meaning of values for the rest of the file, which is designated for defining sequences 
of animations in the sprite sheet. After defining the animation type, it proceeds in 
defieed to 

focus on this part for now, as it will be covered in depth later. 

With the file format out of the way, let's get started with the sprite sheet class! First, 
a container type is defined to hold the animations. An unordered map is used 
because it offers faster lookups than its ordered counter-part: 

using Animations = std :: unordered_map<std :: string, Anim_Base*>; 
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n more depth 

later. Let's write the header for the sprite sheet class: 

class SpriteSheet { 
public : 

SpriteSheet (TextureManager* l_textMgr) ; 

-SpriteSheet ( ) ; 

void CropSprite (const sf::IntRect& l_rect) ; 

... // Basic setters/getters. 

bool LoadSheet (const std : : strings l_file) ; 

void ReleaseSheet ( ) ; 

Anim_Base* GetCurrentAnim ( ) ; 
bool SetAnimation (const std : : strings l_name, 
const bools l_play = false, 
const bools l_loop = false) ; 

void Update (const floats l_dT) ; 
void Draw ( sf : : RenderWindow* l_wnd) ; 
private : 

std:: string m_texture; 
sf::Sprite m_sprite; 
sf::Vector2i m_spriteSize ; 
sf::Vector2f m_spriteScale ; 

Direction redirection; 
std::string m_animType; 

Animations m_animations ; 

Anim_Base* m_animationCurrent ; 

TextureManager* m_textureManager ; 

} ; 

As you can see, it offers methods for cropping the texture and updating and 
anager in 
s that it holds 

a data member of type Direction. It's simply just an enumeration, defined in the 
Directions . h file: 

enum class Directionj Right = 0, Left }; 

ally rely on 

this, so a separate header is where it needs to be. 
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tarting, as 

always, with the constructor and destructor: 

SpriteSheet : : SpriteSheet (TextureManager* l_textMgr) 

: m_textureManager (l_textMgr) , m_animationCurrent (nullptr ) , 
m_spriteScale ( 1 . f , l.f), redirection (Direction :: Right ){ } 

ing else of 
uch like 

a lot of other classes: 

SpriteSheet :: -SpriteSheet () { ReleaseSheet ( ) ; } 

void SpriteSheet : : ReleaseSheet ( ) { 

m_textureManager- >ReleaseResource (m_texture) ; 
m_animationCurrent = nullptr; 

while (m_animations . begin ( ) != m_animations . end ( ) ) { 

delete m_animations . begin ( ) -> second; 
m_animations . erase (m_animations . begin ( ) ) ; 

} 

} 

The ReleaseSheet method uses the texture manager to release the resource it was 
d. 

When setting the sprite size, it's important to also reset the origin, so it's always in 
the middle of the sprite on the x axis and down all the way on the y axis: 

void SpriteSheet SetSpriteSize ( const sf : : Vector2i& l_size) { 
m_spriteSize = l_size; 

m_sprite . setOrigin (m_spriteSize .x / 2, m_spriteSize . y) ; 

} 


void SpriteSheet SetSpritePosition (const sf : : Vector2f& l_pos) { 
m_sprite . setPosition (l_pos) ; 

} 

need to re-crop it 
afterwards: 

void SpriteSheet SetDirection (const Directions; l_dir) { 
if (l_dir == redirection) { return; } 
redirection = l_dir; 
m_animationCurrent- >CropSprite ( ) ; 

} 
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The actual cropping is done through the setTextureRect method of a sprite class: 

void SpriteSheet :: CropSprite (const sf : : IntRect& l_rect) { 
m_sprite . setTextureRect (l_rect) ; 

} 

It takes in a sf : : intRect type, which defines its top-left corner, as well as the size 
of the rectangle. The top-left corner coordinates are local to the texture that's being 
cropped. Let's say we want to obtain the first sprite in the sprite sheet. If we know 
that each sprite is 32px by 32px in size, all we need to do is pass in the position (0;0) 
for the top-left corner and then the size (32;32) in order to obtain the sprite. 

Although we haven't covered animations yet, let's get the Set Animat ion method 
out of the way, since it's not too difficult to understand, even without knowing 
every specific detail about our soon-to-be animation class: 

bool SpriteSheet :: SetAnimation (const std : : strings l_name, 
const bool& l_play, const bool& l_loop) 

{ 

auto itr = inanimations . f ind (l_name) ; 

if (itr == m_animations . end ( ) ) { return false; } 

if (itr->second == m_animationCurrent ) { return false; } 

if (m_animationCurrent) { m_animationCurrent->Stop ( ) ; } 

m_animationCurrent = itr->second; 

m_animationCurrent- > Set Looping ( l_loop) ; 

if (l_play) { m_animationCurrent- >Play ( ) ; } 

m_animationCurrent- >CropSprite () ; 

return true; 

} 

It takes in three arguments: a string handle and two Boolean flags for playing the 
oks through 
If one is 
stopped. Once 

that is done, it simply changes the pointer to the current animation to the animation 
in order to 

loop and play the animation. Nothing too complicated, 
methods: 

void SpriteSheet : :Update (const float& l_dT) { 
m_animationCurrent- >Update (l_dT) ; 

} 

void SpriteSheet Draw ( sf RenderWindow* l_wnd) { 
l_wnd->draw (m_sprite) ; 

} 
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This is about as simple as it gets. However, it does leave us with one method 
unaccounted for: LoadSheet. Before we can implement that, we need to know 
more about the animation classes we'll be working with. 

The base animation class 

ctionality 

that isn't unique to more specific classes and put it in a base class. This is where the 
base animation class comes in. Let's take a look at the Anim_Base . h header file: 

class SpriteSheet; 

using Frame = unsigned int; 

class Anim_Base{ 

friend class SpriteSheet; 
public : 

Anim_Base ( ) ; 
virtual ~Anim_Base ( ) ; 

... // Setters/getters, 
void Play ( ) ; 
void Pause (); 
void Stop ( ) ; 
void Reset ( ) ; 

virtual void Update (const floats l_dT) ; 

friend std : : stringstreams operator >> ( 

std : : stringstreams l_stream, Anim_Base& a) 

{ 

a . Readln ( l_stream) ; 
return l_stream; 

} 

protected: 

virtual void FrameStep ( ) = 0; 
virtual void CropSpriteO = 0; 

virtual void Readln ( std :: stringstreams l_stream) = 0; 

Frame m_f rameCurrent ; 

Frame m_f rameStart ; 

Frame m_frameEnd; 

Frame m_frameRow; 

int m_f rameActionStart ; // Frame when a specific "action" begins 
int m_f rameActionEnd; // Frame when a specific "action" ends 
float m_frameTime; 
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float m_elapsedTime ; 
bool m_loop; 
bool m_playing; 
std : : string m_name; 
SpriteSheet* m_spriteSheet ; 

}; 


First, notice the forward declaration of class SpriteSheet. Because this class needs 
to include SpriteSheet and SpriteSheet needs to include this class, forward 
declarations are necessary to prevent cross-inclusions. We're also going to be using 
an alias for the unsigned integer type, simply named Frame. 

Most of the data member as well as method names are fairly self-explanatory. A few 
he amount 

of time each frame takes to finish. Action defines a range of frames during which a 
behavior which is specific to that animation can be performed. If it's set to negative 
se are some 

things that we want to keep track of in order to make the game more interactive and 
responsive. Note that we're overloading the >> operator in order to ease animation 
loading from files. More on that later. 

The last thing to point out is the three purely virtual methods: FrameStep, 
CropSprite, and Readln. FrameStep is the update portion that's unique to different 
types of animations. CropSprite is a unique way different types of animations 
would obtain sprites from a sprite sheet. Lastly, Readln is the method that defines 
om files. 

These three methods will only be defined in derived classes. 

Implementing the base animation class 

Due to forward declarations, we need to include the actual header files of classes 
that were declared in the . cpp file: 

#include "Anim_Base . h" 

#include "SpriteSheet . h" 

Now we have no more cross-inclusions and we get to use the SpriteSheet class. 
Time to implement the actual class: 

Anim_Base : :Anim_Base() : m_f rameCurrent ( 0 ) , m_f rameStart ( 0 ) , 
m_f rameEnd ( 0 ) , m_f rameRow ( 0 ) , m_f rameTime ( 0 . f ) , 
m_elapsedTime ( 0 . f ) , m_f rameActionStart ( -1 ) , 
m_f rameActionEnd ( - 1 ) , m_loop (false) , m_playing (false) { } 

Anim_Base : : ~Anim_Base ( ) { } 
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, while the 

destructor isn't going to be used at all in this class, 
something: 

void Anim_Base : : SetSpriteSheet (SpriteSheet* l_sheet) { 
m_spriteSheet = l_sheet ; 

} 

thod is 

slightly more intricate: 

void Anim_Base :: SetFrame (const unsigned int& l_frame) { 

if ( (l_frame >= m_frameStart && l_frame <= m_frameEnd) | | 
(l_frame >= m_frameEnd && l_frame <= m_f rameStart ) ) 

{ 

m_f rameCurrent = l_frame; 

} 

} 

The argument that is passed to this method is checked for being in two specific 
ranges, which is done in order to add support for types of animation that can 
play backwards in the future. 

orm its 

custom behavior: 

bool Anim_Base : : IsInAction ( ) { 

if (m_f rameActionStart == -1 | | m_f rameActionEnd == -1) { 
return true; 

} 


return (m_f rameCurrent >= m_f rameActionStart 
&& m_f rameCurrent <= m_f rameActionEnd) ; 

} 

If any of the values are - 1, the "action" is always performed. Otherwise, the current 
ed from the 
sprite sheet file. 
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er. It's a 

good idea to provide a simple interface to do that: 

void Anim Base :: Play () { m_playing = true; } 

void Anim_Base :: Pause () { m_playing = false; } 

void Anim_Base : ; Stop ( ) { m_playing = false; ResetO; } 

The Play and Pause methods simply manipulate a Boolean flag, while the stop 
method also resets the animation: 

void Anim_Base : : Reset ( ) { 

m_f rameCurrent = m_f rameStart ; 
rn_elapsedTime = O.Of; 

CropSprite ( ) ; 

} 

After moving the frame back to the beginning and resetting the timer, it crops the 
All that's 

missing now is a way to update it: 

void Anim_Base Update (const floats l_dT) { 
if ( ! m_playing) { return; } 
m_elapsedTime += l_dT; 

if (m_elapsedTime < m_frameTime) { return; } 

FrameStep ( ) ; 

CropSprite ( ) ; 
m_elapsedTime = 0; 

} 

The Update 
nimation if 
r two virtual 

methods are called and the timer is reset back to o. 
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Directional animation 

There's not always a clear dichotomy present between different types of animation 
depending on implementation details. For the purposes of this chapter not dragging 
on with specific subjects, only one type of animation will be implemented, which 
is the directional animation. This type of animation is usually used with any kind 
of moving entities that have a specific animation for each direction. Unlike other 
types of animation, where an increased frame can lead to a jump in rows, directional 
animation will always remain on the row that represents the proper type of animation 
in the proper direction. Consider the following illustration: 



Frames 

0123... 

Row 0 


Row 1 

&&&&&&&& 

Row 2 


Row 3 

& fit ft 

• • • 



ft 
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on of a specific 
ation class: 

class Anim_Directional : public Anim_Base{ 
protected: 

void FrameStep ( ) ; 
void CropSprite ( ) ; 

void Readln ( std : : stringstreamk l_stream) ; 


three methods 
nclusion 

of the Sprites he et.h file due to its forward declaration in the header of the 
Anim_Base class: 

#include "Anim_Directional . h" 

#include "SpriteSheet . h" 
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Now let's slice through that texture to fashion our sprite: 

void Anim_Directional : : CropSprite ( ) { 
sf::IntRect rect ( 

m_spriteSheet - >GetSpriteSize ( ) . x * m_f rameCurrent , 
m_spriteSheet->GetSpriteSize ( ) .y * 

(m_frameRow + ( short ) m_spriteSheet- >GetDirection ()) , 
m_spriteSheet - >GetSpriteSize ( ) .x, 
m_spriteSheet - >GetSpriteSize ( ) .y) ; 
m_spriteSheet - >CropSprite (rect) ; 

} 

ite size multiplied 

by the current frame on the x axis and the sprite size multiplied by the sum of the 
current animation row and the sprite sheet direction on the y axis. Because the 

0 or l, it 

above. After 
crop the sprite 
te! 

The fi 

FrameStep method: 

void Anim_Directional : : FrameStep ( ) { 

if (m_f rameStart < m_frameEnd) { ++m_f rameCurrent ; } 
else { - -m_f rameCurrent ; } 

if ( (m_f rameStart < m_frameEnd && m_f rameCurrent > m_frameEnd) | 
(m_f rameStart > m_frameEnd && m_f rameCurrent < m_frameEnd) ) 

{ 

if (m_loop) { m_f rameCurrent = m_f rameStart ; return; } 
m_f rameCurrent = m__frameEnd; 

Pause ( ) ; 

} 

} 

First, we check which direction we should roll the frames in, since it could be 
necessary in the future to define backwards-moving animations. If the starting 
positive 
ther it is 

looping or not, we either reset the current frame to start, or set it to the end of the 
playing 

backwards, except the direction is reversed. 


[ 149 ] 



Set It in Motion! - Animating and Moving around Your World 


Lastly, the method responsible for reading in data from files: 

void Anim_Directional : : Readln ( std : : stringstreamk l_stream) { 
l_stream >> m_frameStart >> m_frameEnd >> m_frameRow 

>> m_frameTime >> m_f rameActionStart >> m_f rameActionEnd; 

} 

With that final bit of code, the animation portion is finished! Everything we need in 
order to implement loading the sprite sheet file is now available. 

Loading the sprite sheet files 

The loading method begins, as per usual, by setting up the file, reading it, and 
obtaining the current line. The first identifier from the line is loaded into the 
type variable. The rest is fairly typical: 

bool SpriteSheet :: LoadSheet ( const std::string& l_file) { 
std: : if stream sheet; 

sheet . open (Utils :: GetWorkingDirectory ( ) + l_file) ; 
if (sheet . is_open ( ) ) { 

ReleaseSheet ( ) ; // Release current sheet resources. 
std::string line; 
while ( std : : get line ( sheet , line) ) { 
if (line[0] == '|'){ continue; } 
std: : stringstream keystream ( line) ; 
std:: string type; 
keystream >> type; 


} 

sheet . close ( ) ; 
return true; 

} 

std::cerr << "! Failed loading spritesheet: " 

<< l_file << std::endl; 
return false; 

} 

n this file has 

been split up into separate sections. Let's begin with the texture loading: 

if (type == "Texture"){ 
if (m_texture != ""){ 

std: :cerr << "! Duplicate texture entries in: " 

<< l_file << std::endl; 
continue ; 
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} 

std: : string texture; 

keystream >> texture; 

if ( ! m_textureManager- >RequireResource (texture) ) { 
std: : cerr << "! Could not set up the texture: " 

<< texture << std::endl; 
continue ; 

} 

m_texture = texture; 

m_sprite . setTexture ( *m_textureManager- >GetResource (m_texture) ) ; 

} else if ... 

First, we check if the texture hasn't been initialized already in order to avoid 
duplicate entries. If it hasn't, the keystream variable spits out the texture handle, 
which gets passed into the texture manager in an if statement. This is done to catch 
ept around for 
set to point 
to the texture. 

Time to read the smaller bits of information in: 

} else if (type == "Size"){ 

keystream >> m_spriteSize . x >> m_spriteSize . y ; 

SetSpriteSize (m_spriteSize) ; 

} else if (type == "Scale") { 

keystream >> m_spriteScale . x >> m_spriteScale . y ; 
m_sprite . setScale (m_spriteScale) ; 

} else if (type == "AnimationType " ) { 
keystream >> m_animType; 

} else if ... 

The most dramatic entry has been saved for last. At this moment, we parse the 
animations: 

} else if (type == "Animation")! 

std:: string name; 

keystream >> name; 

if (inanimations . find (name) != m_animations . end ( ) ) { 
std: :cerr << "! Duplicate animation(" << name 
<< ") in: " << l_file << std::endl; 
continue ; 

} 

Anim_Base* anim = nullptr; 

if (m_animType == "Directional")! 
anim = new Anim_Directional ( ) ; 

} else { 
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std::cerr << "! Unknown animation type: " 
<< m_animType << std::endl; 
continue ; 

} 

keystream >> *anim; 
anim- >SetSpriteSheet ( this ) ; 
anim- >SetName (name) ; 
anim- >Reset ( ) ; 

m_animations . emplace (name , anim) ; 


if (m_animationCurrent) { continue; } 
rn_animationCurrent = anim; 
m_animationCurrent- >Play ( ) ; 

} 

First, the animation name gets loaded and the animation container is checked in order 
to avoid duplicates. The type of animation that was loaded previously is then checked 
in order to construct a correct animation type. We could use a factory method for 
this, but since we only have one type of animation so far, it seems pointless at this 
time. The animation structure then gets data streamed into it from our stringstream 
object, initializing it. Furthermore, the animation is reset in order to zero-out its 
values. Once it gets inserted into the animation container, the last thing we check for 
is whether the current animation member has been assigned a value yet. If it hasn't, 
this is the first animation in the sprite sheet file, which we're assuming is the default. 

It gets assigned to the current animation member and set to play. 

Summary 

ing 

from basic shapes to actual sprites being animated on screen can make a world of 
difference in the eyes of a player. Granted, prettifying a product doesn't fix whatever 
fig the 
emed like a 
of this chapter, 

you are now able to achieve with a few basic techniques, 
s that 

will unify all of the graphical bits and pieces we built into a fully functional game 
with platforming elements, enemies, and multiple levels. See you there! 
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innovative 
e games, such 

as Minecraft and Super Meat Boy. While the game ideas themselves are getting more 
and more abstract, at least on the outside, the rigid skeleton behind the pretty skin 
that keeps it standing and helps it retain shape is still taking the place of the lowest 
common denominator in the eyes of game developers. Even if the focus of the 
game centers around two unicorns who spend their free time smoking fairy dust 
and helping Dracula make muffins so that Neptune doesn't blow up, that concept 
coming to life is going to depend greatly on the underlying logic of the game before 
anything else. If there are no entities in the game, there are no unicorns. If the entities 
se are the 

most common game design elements that any project must be able to fall back on, 
otherwise it is doomed to fail. 

In this chapter, we will be covering the following: 

• Designing and implementing the game map class 

• Populating the map by creating and managing entities 

• Checking for and handling collisions 

• Meshing all of our code together into a finished game 
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The game map 

portant 

as the rest of the game. Without the world being present, the player is simply left 
terface to 

bring out various parts of the game, ranging from the level backdrop to numerous 
tion for that 

right now, starting with defining what our map format is going to be like, as we 
take a look ahead to determine what we want to accomplish: 



First, we want to specify a texture handle as the background. Then, we want to 
clearly define the map size and set up the gravity, which determines how fast 
friction, which 
o store is the 
reached. 

Here is a snippet from one of the maps that we will be working with, Mapl . map: 


I type | ~id|x|y| 
BACKGROUND Bgl 
SIZE 63 32 
GRAVITY 512 

DEFAULT_FRICTION 0.8 0 
NEXTMAP map2 . map 
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| PLAYER 0 512 
| ENEMY Rat 128 512 
TILE 0 0 25 
TILE 1 0 26 WARP 


As you can tell, in addition to defining all of the things discussed, the map file also 
stores the player position, as well as different enemies and their spawn positions. The 
last but definitely not the least important part of it is tile storage and the indication of 


What is a tile? 

The term "tile" keeps getting thrown around, but it hasn't been defined yet. To put it 
are blocks 

that create the game environment, whether it's the grass you're standing on or the 
imilar to a sprite 
nee is how 

those sprites are obtained from the tile sheet. This is what the texture that is going 
to be used as a tile sheet looks like in our case: 



r 


e 

Tiles . cfg file: 

| id | name | friction x| friction y| deadly 

0 Grass 0.8 0 0 

1 Dirt 0.8 0 0 

2 Stone 0.800 

3 Brick 0.800 

4 Brick_Red 0.800 

5 Rock 0.800 

6 Icy_Rock 0.6 0 0 

7 Spikes 1.001 

8 Ice 0.25 0 0 

ction, and 

a binary flag for the tile being deadly to touch. 
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Building the game world 

uld be greatly 

helpful to have a separate data structure that all tile information can be localized 
to. A good place to start is by defining some constants of the tile size, as well as 
ation 

can be quite helpful when storing this information: 

enum Sheet{Tile_Size = 32, Sheet_Width = 256, Sheet_Height = 256}; 

Here, we make it so all tiles are going to be 32 px wide and 32 px tall and every single 
tile sheet is going to be 256 px wide and 256 px tall. These constants, obviously, can be 
changed, but the idea here is to keep them the same during runtime. 

To keep our code a little shorter, we can also benefit from a type alias for tile IDs: 

using TilelD = unsigned int ; 

The flyweight pattern 

Each tile, obviously, has to have a sprite that represents its type graphically 

be cropped to 

screen and draw 

a map that's 

les that aren't 

. Now imagine 

you're storing a sprite with each tile. Granted, sprites are lightweight objects, but 
that's still a huge waste of resources. This is where the flyweight pattern comes in. 

ust store 

one instance of each type and simply store a pointer to the type in the tile? That, 
in a nutshell, is the flyweight pattern. Let's see it in action, by implementing a tile 
information structure: 

struct Tilelnfoj 

Tilelnfo (SharedContext* l_context, 

const std :: string& l_texture = TilelD l_id = 0) 

: m_context (l_context) , m_id(0), m_deadly (false) 

{ 

TextureManager* tmgr = l_context- >m_textureManager ; 
if (l_texture == ""){ m_id = l_id; return; } 
if ( ! tmgr- >RequireResource (l_texture) ) { return; } 
m_texture = l_texture; 
m_id = l_id; 

m_sprite . setTexture ( *tmgr- >GetResource (m_texture) ) ; 
sf::IntRect tileBoundaries (m_id % 
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(Sheet :: Sheet_Width / Sheet :: Tile_Size) * Sheet :: Tile_Size , 
m_id/ (Sheet : : Sheet_Height/ Sheet : : Tile_Size) * Sheet : : Tile_Size , 
Sheet: : Tile_Size , Sheet : :Tile_Size) ; 
m_sprite . setTextureRect (tileBoundaries) ; 


-Tilelnfo ( ) { 

if (m_texture == ""){ return; } 

m_context - >m_textureManager- >ReleaseResource (m_texture) ; 

} 


sf::Sprite m_sprite; 

TilelD m_id; 
std : : string m_name; 
sf::Vector2f m_friction; 
bool m_deadly; 

SharedContext* m_context ; 
std:: string m_texture; 

} ; 


This struct essentially holds everything about every tile type that isn't unique. It 
stores the texture that it's using, as well as the sprite that will represent the tile. As 
point to the tile 
ng is a little 
ve the tile 
e basic 

math allows us to first figure out how many columns and rows the tile sheet has, 

56 px sized 
ow and column. 

Obtaining the coordinate of a tile ID on an x axis can be done by using the modulus 
operator %based 

on the ID. Figuring out the y coordinate is done simply by dividing the ID by the 
tile sprite in 

the tile sheet, so we finish the cropping by passing in the Sheet : : Tile_Size. 

The Tilelnfof 
loaded. Now 

let's define our tile structure: 

struct Tile{ 

Tilelnfo* m_properties ; 

bool m_warp; // Is the tile a warp. 

// Other flags unique to each tile. 

} ; 
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This is the reason why the flyweight pattern is so powerful. The tile objects are 
incredibly lightweight, if they only store information that can be unique to each tile 
and not the tile type. The only flag we're interested in so far is if the tile is a warp, 
which means it loads the next level when the player is standing on it. 

Designing the map class 

ch as the 

game map. Let's begin by creating a few suitable types of containers that will hold 
the map information, as well as the tile type information: 

using TileMap = std :: unordered_map<TileID, Tile* > ; 
using TileSet = std : : unordered_map<TileID, Tilelnf o* > ; 

The TileMap type is an unordered_map container, which holds pointers to Tile 
objects that are addressed by an unsigned integer. 

In cases where tile counts are known in advance, it would be prudent 
to use a container that will not change in size (such as std : : array or 
a pre-allocated std : : vector) in order to achieve continuous storage, 
and in turn, much faster access. 

ng the 
bers? Well, 

with a little bit of mathematics, it's entirely possible to manipulate indices of two 
dimensions to be represented as a single number. This will be covered shortly. 

The TileSet data type represents the container of all different types of tiles, which 
are tied to a tile ID that's represented by the unsigned integer. This brings us 
everything we need in order to write the map header file, which might look 
a little something like this: 

class Map{ 
public : 

Map (SharedContext* l_context, BaseState* l_currentState) ; 

-Map ( ) ; 

Tile* GetTile (unsigned int l_x, unsigned int l_y) ; 

Tilelnfo* GetDef aultTile ( ) ; 

float GetGravity () const ; 

unsigned int GetTileSize () const ; 

const sf : : Vector2u& GetMapSize () const ; 

const sf : : Vector2f & GetPlayerStart () const ; 

void LoadMap (const std::string& l_path) ; 

void LoadNext ( ) ; 

void Update (float l_dT) ; 

void Draw ( ) ; 
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private : 

// Method for converting 2D coordinates to ID ints. 

unsigned int ConvertCoords (unsigned int l_x, unsigned int l_y) ; 

void LoadTiles (const std :: strings l_path) ; 

void PurgeMap ( ) ; 

void PurgeTileSet ( ) ; 

TileSet m_tileSet; 

TileMap m_tileMap; 

sf : : Sprite m_background ; 

Tilelnfo m_def aultTile ; 

sf::Vector2u m_maxMapSize ; 

sf::Vector2f m_playerStart ; 

unsigned int m_tileCount; 

unsigned int m_tileSetCount ; 

float m_mapGravity; 

std: : string m_nextMap; 

bool m_loadNextMap ; 

std: : string m_backgroundTexture ; 

BaseState* m_currentState ; 

SharedContext* m_context; 

}; 

First, we define all the predictable methods, such as obtaining a tile at specific 
coordinates, getting various information from the class, and, of course, methods 
these 

methods, in order to talk about them more in depth: 

Map :: Map (SharedContext* l_context, BaseState* l_currentState) 
:m_context (l_context) , m_def aultTile (l_context) , 

m_maxMapSize (32 , 32), m_tileCount ( 0 ) , m_tileSetCount ( 0 ) , 
m_mapGravity (512 . f ) , m_loadNextMap (false) , 
m_currentState (l_currentState) 

{ 

m_context - >m_gameMap = this; 

LoadTiles ( "tiles . cfg" ) ; 

} 

The map constructor initializes its data members to some default values and calls 
a private method in order to load different types of tiles from the tiles. cfg file, 
othing out 

of the ordinary either: 


Map : : -Map ( ) { 

PurgeMap ( ) ; 
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PurgeTileSet () ; 

m_context - >m_gameMap = nullptr; 

} 

Obtaining tiles from the map is done by first converting the 2D coordinates provided 

specific tile 

in an unordered map: 

Tile* Map :: GetTile (unsigned int l_x, unsigned int l_y) { 
auto itr = m_tileMap . f ind (ConvertCoords (l_x, l_y) ) ; 
return(itr != m_tileMap . end ( ) ? itr->second : nullptr); 

} 

The conversion of coordinates looks like this: 

unsigned int Map :: ConvertCoords ( const unsigned int& l_x, 
const unsigned int& l_y) 

{ 

return (l_x * m_maxMapSize . x) + l_y; // Row-major. 

} 

In order for this to work, we must have the maximum size of the map defined, 
otherwise it will produce wrong results. 

Updating the map is another crucial part: 

void Map :: Update ( float l_dT) { 
if (m_loadNextMap) { 

PurgeMap ( ) ; 

m_loadNextMap = false; 
if (m_nextMap != ""){ 

LoadMap ( "media /maps / " +m_nextMap) ; 

} else { 

m_currentState- >GetStateManager ( ) - > 

SwitchTo (StateType : ;GameOver) ; 

} 

m_nextMap = " " ; 

} 

sf : : FloatRect viewSpace = m_context->m_wind->GetViewSpace ( ) ; 
m_background . setPosition (viewSpace . left , viewSpace . top) ; 

} 
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Here, it checks the m_loadNextMap flag. If it's set to true, the map information gets 
purged and the next map is loaded, if the data member that holds its handle is set. If 
it isn't, the application state is set to GameOver, which will be created later. This will 
simulate the player beating the game. Finally, we obtain the view space of the window 
and set our map background's top-left corner to the view space's left corner in order for 
the background to follow the camera. Let's draw these changes on the screen: 

void Map: :Draw() { 

sf : : RenderWindow* l_wind = m_context- >m_wind- >GetRenderWindow ( ) ; 

l_wind- >draw (m_background) ; 

sf : : FloatRect viewSpace = m_context->m_wind->GetViewSpace ( ) ; 

sf::Vector2i tileBegin( 

floor (viewSpace . left / Sheet :: Tile_Size) , 
floor (viewSpace . top / Sheet :: Tile_Size) ) ; 

sf::Vector2i tileEnd( 

ceil ( (viewSpace . left + viewSpace . width) / Sheet :: Tile_Size) , 
ceil ( (viewSpace . top + viewSpace . height) / Sheet :: Tile_Size) ) ; 

unsigned int count = 0; 

for(int x = tileBegin.x; x <= tileEnd.x; ++x) { 
for(int y = tileBegin.y; y <= tileEnd.y; ++y) { 
if (x < 0 || y < 0) { continue; } 

Tile* tile = GetTile (x, y) ; 
if Utile) { continue; } 

sf::Sprite& sprite = tile- >m_properties- >m_sprite ; 
sprite . setPosition (x * Sheet :: Tile_Size , 
y * Sheet :: Tile_Size) ; 
l_wind- >draw ( sprite) ; 

++count ; 

} 

} 

} 

A pointer to the render window is obtained through the share context and the 
background is drawn in the first two lines here. The next three lines serve a purpose, 
simply known by a name of culling. It is a technique that any good game programmer 
should utilize, where anything that's not currently within the view space of the screen 
should be left undrawn. Once again, consider the situation where you have a massive 
map of size 1000x1000. Although modern hardware nowadays could draw that really 
fast, there's still no need to waste those clock-cycles when they could instead be used 
to perform a much better task, instead of bringing something to the screen that isn't 
even visible. If you are not culling anything in your game, it will eventually start 
taking serious performance hits. 
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ace to its 

bottom-right corner are fed into a loop. First, they get evaluated to be positive, 
iner will 

produce some mirroring artifacts, where the same map you see will be repeated 
over and over again if you go up or left far enough. 

A pointer to a tile is obtained by passing in the x and y coordinates from the loop. If 
it is a valid tile, we obtain its sprite from the pointer to the Tilelnf o structure. The 
he sprite is drawn 
on screen. 

Now for a way to erase the entire map: 

void Map : : PurgeMap ( ) { 
m_tileCount = 0; 
for (auto &itr : m_tileMap) { 
delete itr. second; 

} 

m_tileMap . clear ( ) ; 

m_context - >m_entityManager- >Purge () ; 

if (m_backgroundTexture == ""){ return; } 
m_context - >m_textureManager- > 

ReleaseResource (m_backgroundTexture) ; 
np_backgroundTexture = " " ; 

} 

lling the Purge 

method of an entity manager. For now, ignore that line. Entities will be covered 
shortly. We must also not forget to free up the background texture when erasing 
the map. 

Emptying the container of different tile types is also a necessary part: 

void Map : : PurgeTileSet ( ) { 

for (auto &itr : m_tileSet) { 
delete itr. second; 

} 

m_tileSet . clear ( ) ; 
m_tileSetCount = 0; 

} 


[ 162 ] 



Chapter 7 

ice to have a 
in from a file: 

void Map :: LoadTiles (const std::string& l_path) { 
std: : if stream file; 

file . open (Utils :: GetWorkingDirectory ( ) + l_path) ; 
if ( ! f ile . is_open ( ) ) { 

std::cout << "! Failed loading tile set file: " 

<< l_path << std::endl; 
return ; 

} 

std::string line; 
while ( std : : get line ( f ile , line) ) { 
if (line[0] == '|'){ continue; } 
std: : stringstream keystream ( line) ; 
int tileld; 
keystream >> tileld; 
if (tileld < 0) { continue; } 

Tilelnfo* tile = new Tilelnfo (m_context , "TileSheet ", tileld) ; 
keystream >> tile->m_name >> tile- >m_f riction . x 
>> tile->m_friction.y >> tile- >m_deadly ; 
if ( !m_tileSet . emplace (tileld, tile) . second) { 

// Duplicate tile detected! 
std::cout << "! Duplicate tile type: " 

<< tile->m_name << std::endl; 
delete tile; 

} 

} 

file . close ( ) ; 

} 

The tile ID gets loaded first, as the tiles. cfg format suggests. It gets checked for 
e tile type, 
alues from 

the string stream. If the tile information object cannot be inserted into the tile set 
-allocated. 

Now for the grand finale of the map - the loading method. Since the actual file 
he contents 

of the map file, starting with tile entries: 

if (type == " TILE " ) { 
int tileld = 0; 
keystream >> tileld; 

if (tileld < 0) { std::cout << "! Bad tile id: " 

<< tileld << std::endl; 
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continue ; 

} 

auto itr = m_tileSet . f ind (tileld) ; 
if (itr == m_tileSet . end ( ) ) { 

std::cout << "! Tile id ( " << tileld 

<< ") was not found in tileset." << std::endl; 
continue ; 

} 

sf::Vector2i tileCoords; 

keystream >> tileCoords. x >> tileCoords . y; 

if ( tileCoords . x>m_maxMapSize . x || tileCoords . y>m_maxMapSize . y) 

{ 

std::cout << "| Tile is out of range: " << 

tileCoords. x << " " << tileCoords. y << std::endl; 
continue ; 

} 

Tile* tile = new TileO ; 

// Bind properties of a tile from a set. 
tile- >m_properties = itr->second; 
if ( ! m_tileMap . emplace (ConvertCoords ( 

tileCoords .x, tileCoords .y) , tile) .second) 

{ 

// Duplicate tile detected! 

std : : cout << " ! Duplicate tile! : " << tileCoords. x 
<< "" << tileCoords. y << std::endl; 
delete tile; 
tile = nullptr; 
continue ; 

} 

std:: string warp; 
keystream >> warp; 
tile->m_warp = false; 

if (warp == "WARP" ) { tile->m_warp = true; } 

} else if ... 

The first segment of the tile line is loaded in, which is the tile ID. It is checked, 

as per usual, to be within the boundaries of positive numbers and 0 . If it is, the tile 

information of that specific tile ID is looked up in the tile set. Because we don't want 

he specific 

ing within the 

cated and its tile 

et. Lastly, we 

attempt to read in a string at the end of the TILE line and check if it says "WARP". 
That's the indication that touching a specific tile should load the next level. 
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Now for the background of the map: 

} else if (type == " BACKGROUND ") { 

if (m_backgroundTexture != ""){ continue; } 
keystream >> m_backgroundTexture ; 
if ( ! m_context - >m_textureManager- > 

RequireResource (m_backgroundTexture) ) 

{ 

m_backgroundTexture = " " ; 
continue ; 

} 

sf::Texture* texture = m_context- >m_textureManager- > 

GetResource (m_backgroundTexture) ; 
m_background . setTexture (* texture) ; 

sf::Vector2f viewSize = m_currentState- >GetView ( ) . getSize ( ) ; 
sf::Vector2u textureSize = texture- >getSize () ; 
sf::Vector2f scaleFactors; 

scaleFactors . x = viewSize. x / textureSize . x; 
scaleFactors . y = viewSize. y / textureSize . y; 
m_background . setScale (scaleFactors) ; 

} else if ... 

This one is quite straightforward. A texture handle gets loaded from the BACKGROUND 
line. If the handle is valid, the background sprite gets tied to the texture. There is a 
catch though. Let's say that the view of our window is larger than the texture of the 
background. That would result in empty areas all around the background, which looks 
horrendous. Repeating the texture might remedy the empty areas, but the specific 
backgrounds we're going to be working with don't tile well, so the best solution is to 
scale the sprite enough to fit the view space fully, whether it’s larger or smaller. The 
factors of the scaling can be obtained by multiplying the size of the view by the size of 
the texture. If, for example, we have a view that's 800x600 px large and a texture of a 
size 400x300 px, the scale factor for both axes would be 2 and the background is scaled 
up to twice its size. 

Next is the easy part of simply reading in some data members from a file: 

} else if (type == "SIZE"){ 

keystream >> m_maxMapSize . x >> m_maxMapSize . y ; 

} else if (type == "GRAVITY") { 
keystream >> m_mapGravity ; 

} else if (type == "DEFAULT_FRICTION" ) { 

keystream >> m_def aultTile- >m_f riction . x 
>> m_def aultTile- >m_f riction . y; 

} else if (type == "NEXTMAP"){ 
keystream >> m_nextMap; 

} 


[ 165 ] 



Rediscovering Fire - Common Game Design Elements 


eep track of 

when the next map should be loaded: 

void Map : : LoadNext ( ) { m_loadNextMap = true; } 

This concludes the map class implementation. The world now exists, but nobody is 
e entities 

to explore the environments we conjure up. 

The parent of all world objects 

stract class 
r, enemies, 
ing 

mmer to 
defihe game 
rface. For 
ems, and 

the player have to be affected by gravity as well. Having that common ancestry 
between these different types allows us to offload a lot of redundant code and focus 
on the aspects that are unique to each entity, instead of re-writing the same code over 
and over again. 

Let's begin by defining what entity types we're going to be dealing with: 

enum class EntityTypej Base, Enemy, Player }; 

The base entity type is just the abstract class, which will not actually be instantiated, 
states an 
entity can have: 

enum class EntityStatej 

Idle, Walking, Jumping, Attacking, Hurt, Dying 

} ; 


You have probably noticed that these states vaguely match the animations from the 
player sprite sheet. All character entities will be modeled this way. 

Creating the base entity class 

In cases where entities are built using inheritance, writing a basic parent class like 
any given 

entity within the game should have. 
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With all of the setting up out of the way, we can finally start shaping it like so: 

class EntityManager; 
class EntityBase{ 
friend class EntityManager; 
public : 

EntityBase (EntityManager* l_entityMgr) ; 
virtual -EntityBase () ; 

... // Getters and setters . 
void Move (float l_x, float l_y) ; 
void AddVelocity ( float l_x, float l_y) ; 
void Accelerate ( float l_x, float l_y) ; 
void SetAcceleration ( float l_x, float l_y) ; 
void ApplyFriction ( float l_x, float l_y) ; 
virtual void Update (float l_dT) ; 

virtual void Draw (sf : : RenderWindow* l_wind) = 0; 
protected: 

/ / Methods . 
void UpdateAABB ( ) ; 
void CheckCollisions ( ) ; 
void ResolveCollisions ( ) ; 

// Method for what THIS entity does TO the l_collider entity, 
virtual void OnEntityCollision (EntityBase* l_collider, 
bool l_attack) = 0; 

/ / Data members . 
std::string m_name; 

EntityType m_type; 

unsigned int m_id; // Entity id in the entity manager. 
sf::Vector2f m_position; // Current position. 
sf::Vector2f m_position01d; // Position before entity moved. 
sf::Vector2f m_velocity; // Current velocity. 
sf::Vector2f m_maxVelocity ; // Maximum velocity. 
sf::Vector2f m_speed; // Value of acceleration. 
sf::Vector2f m_acceleration; // Current acceleration. 
sf::Vector2f m_friction; // Default friction value. 

Tilelnfo* m_ref erenceTile ; // Tile underneath entity. 
sf::Vector2f m_size; // Size of the collision box. 
sf : : FloatRect m_AABB ; // The bounding box for collisions. 
EntityState m_state; // Current entity state. 

// Flags for remembering axis collisions, 
bool m_collidingOnX ; 
bool m_collidingOnY; 

Collisions m_collisions ; 

EntityManager* m_entityManager ; 

} ; 
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Right off the bat, we set up the EntityManager class that we haven't written yet to 
le confusing, 

a barrage of comments was added to explain every data member of the class, so 
g the 

implementation of the class. 

The three major properties of an entity include its position, velocity, and acceleration, 
ow fast an entity 
the delta 

time in seconds, the velocity is going to represent the number of pixels that an entity 
moves across per second. The last element of the major three is acceleration, which 
defined as the 
sequence of 

events here is as follows: 

1. The entity is accelerated and its acceleration adjusts its velocity. 

2. The entity's position is re-calculated based on its velocity. 

3. The velocity of an entity is damped by the friction coefficient. 

Collisions and bounding boxes 

Before jumping into implementations, let's talk about one of the most commonly used 
elements in all games - collisions. Detecting and resolving a collision is what keeps 
the player from falling through the map or going outside the screen. It's also what 
determines if a player gets hurt if they get touched by the enemy. In a round-about 
way, we used a basic form of collision detection in order to determine which tiles we 
should render in the map class. How does one detect and resolve collisions? There 
are many ways to do so, but for our purposes, the most basic form of a bounding box 
collision will do just fine. Other types of collisions that incorporate different shapes, 
such as circles, can also be used, but may not be the most efficient or appropriate 
depending on the kind of game that's being built. 
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sents the 

solid portion of an entity. Here's a good example of a bounding box: 
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It isn't visible like that, unless we create an actual sf : : RectangleShape with the 
seful way to 

debug your applications. In our base entity class, the bounding box named m_AABB 
is simply a sf : : FloatRect type. The name "AABB" represents two pairs of different 
values it holds: the position and the size. Bounding box collision, also referred to as 
an AABB collision, is simply a situation where two bounding boxes intersect with 
hat checks 
for intersections: 

if (m_AABB . intersects (SomeRectangle) { . . . } 

The term collision resolution simply means performing some sequence of actions in 
with tiles, for 
enough so 

it isn't intersecting with the tile any more. 



The code files of this project contain an additional class that allows 
of 

information already set up. Hitting the O key will toggle its visibility. 
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Implementing the base entity class 

With all of that information out of the way, we can finally return to implementing the 
base entity class. As always, what better place is there to start than the constructor? 
Let's take a look: 

EntityBase: : EntityBase (EntityManager* l_entityMgr) 

: m_entityManager ( l_entityMgr) , m_name ( "BaseEntity" ) , 
m_type (EntityType : :Base) , m_ref erenceTile (nullptr ) , 
m_state (EntityState : : Idle) , m_id (0) , 
m_collidingOnX (false) , m_collidingOnY (false) {} 

that out of all the 

members it sets to zero, the friction actually gets set up for the x axis to be 0.8. This is 
because we don't want the default behavior of the entity to be equal to that of a cow 
on ice, to put it frankly. Friction defines how much of the entity's velocity is lost to 
re about 

to cover it in greater detail, 
base class: 

void EntityBase :: SetPosition (const floats l_x, const floats 1 y ) { 

m_position = sf : : Vector2f (l_x, l_y) ; 

UpdateAABB ( ) ; 

} 

void EntityBase :: SetPosition (const sf : : Vector2f & l_pos) { 
m_position = l_pos; 

UpdateAABB () ; 

} 

void EntityBase :: SetSize (const floats l_x, const floats l_y) { 
m_size = sf : : Vector2f (l_x, l_y) ; 

UpdateAABB () ; 

} 

void EntityBase :: SetState ( const EntityStateS l_state) { 
if (m_state == EntityState :: Dying) { return; } 
m_state = l_state; 

} 

ts in a call 

of the internal method UpdateAABB. Simply put, it's responsible for updating the 
position of the bounding box. More information on that is coming soon. 

One interesting thing to note is in the SetState method. It does not allow the state to 
change if the current state is Dying. This is done in order to prevent some other event 
in the game to snap an entity out of death magically. 
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entity: 

void EntityBase :: Move ( float l_x, float l_y) { 
m_position01d = m_position; 
m_position += sf : :Vector2f (l_x, l_y) ; 
sf::Vector2u mapSize = m_entityManager- > 

GetContextO - >m_gameMap- >GetMapSize ( ) ; 
if (m_position . x < 0) { 
m_position.x = 0; 

} else if (m_position . x > (mapSize. x + 1) * Sheet :: Tile_Size) { 
m_position.x = (mapSize. x + 1) * Sheet :: Tile_Size ; 

} 

if (m_position.y < 0) { 
m_position.y = 0; 

} else if (m_position.y > (mapSize. y + 1) * Sheet :: Tile_Size) { 
m_position.y = (mapSize. y + 1) * Sheet :: Tile_Size ; 

SetState (EntityState : :Dying) ; 

} 

UpdateAABB ( ) ; 

} 

First, we copy the current position to another data member: m_position01d. It's 
Then, the 
ize of the 
eing outside 
ething that's at 

the very edge of the out-of-bounds area. In the case of the entity being outside of 
the map on the y axis, its state is set to Dying. After all of that, the bounding box is 
updated in order to reflect the changes to the position of the entity sprite. 

Now let's work on adding to and managing the entity's velocity: 

void EntityBase : :AddVelocity (float l_x, float l_y) { 
m_velocity += sf : :Vector2f (l_x, l_y) ; 
if (abs (m_velocity .x) > m_maxVelocity.x) { 

if (m_velocity . x < 0) { m__velocity.x = -m_maxVelocity . x; } 
else { m_velocity.x = m_maxVelocity . x; } 

} 

if (abs (m__velocity .y) > m_maxVelocity.y) { 

if (m_velocity .y < 0) { m_velocity.y = -m_maxVelocity . y ; } 
else { m_velocity.y = m_maxVelocity . y ; } 

} 

} 
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As you can see, it's fairly simple stuff. The velocity member is added to and then 
checked for being outside of the bounds of allowed maximum velocity. In the 
fitive and 
elocity is out 

of bounds, it gets reset to the maximum allowed value it can have, 
to another: 

void EntityBase : :Accelerate (float l_x, float l_y) { 
m_acceleration += sf : :Vector2f (l_x, l_y) ; 

} 

Applying friction is no more complex than managing our velocity: 

void EntityBase : : ApplyFriction (float l_x, float l_y) { 
if (m_velocity . x != 0){ 

if (abs (m_velocity . x) - abs(l_x) < 0){ m__velocity.x = 0; } 
else { 

if (m__velocity . x < 0) { m_velocity.x += l_x; } 
else { m_velocity.x -= l_x; } 

} 

} 


if (m_velocity . y != 0){ 

if (abs (m_velocity .y) - abs(l_y) < 0) { m_velocity.y = 0; } 

else { 

if (m__velocity . y < 0) { m_velocity.y += l_y; } 
else { m_velocity.y -= l_y; } 

} 

} 

} 

the velocity 

and the friction coefficient on that axis isn't less than zero, in order to prevent 
would 

zero. If it isn't, 
pplied. 

In order for an entity to not be a static part of the backdrop, it needs to be updated: 

void EntityBase :: Update ( float l_dT) { 

Map* map = m_entityManager- >GetContext ( ) - >m_gameMap ; 
float gravity = map- >GetGravity ( ) ; 

Accelerate ( 0 , gravity) ; 

AddVelocity (m_acceleration . x * l_dT, m_acceleration . y * l_dT); 
SetAcceleration ( 0 . Of , O.Of); 
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sf::Vector2f f rictionValue ; 
if (m_referenceTile) { 

f rictionValue = m_ref erenceTile- >m_f riction; 

if (m_referenceTile- >m_deadly) { SetState (EntityState : :Dying) ; } 
} else if (map- >GetDef aultTile ( ) ) { 

f rictionValue = map- >GetDef aultTile ()- >m_f riction; 

} else { 

f rictionValue = m_friction; 

} 


float friction_x = (m_speed.x * f rictionValue . x) * l_dT; 
float friction_y = (m_speed.y * f rictionValue . y) * l_dT; 
ApplyFriction ( f riction_x, friction_y) ; 
sf::Vector2f deltaPos = m_velocity * l_dT; 

Move (deltaPos .x, deltaPos. y); 
m_collidingOnX = false; 
m_collidingOnY = false; 

CheckCollisions ( ) ; 

ResolveCollisions ( ) ; 

} 


Quite a bit is happening here. Let's take it step by step. First, an instance of the 
in the 

gravity of the map, which was loaded from the map file. The entity's acceleration 
is then increased by the gravity on the y axis. By using the AddVelocity method 
s adjusted 
ion coefficient 

that the velocity will be damped by. The m_ref erenceTile data member, if it's not 
set to nullptr, is used first, in order to obtain the friction from a tile the entity's 
standing on. If it is set to nullptr, the entity must be in mid-air, so the default tile 
om the map 
fivalue set in the 
EntityBase's constructor. 

Before we get to calculating friction, it's important to clarify that the m_speed data 
to a default 

value. The speed is how much an entity is accelerated when it's moving and it 
will be implemented in one of the derived classes of EntityBase. 
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If you recall from the constructor of this class, we set up the default friction to be 
s a factor in 
said that, 

multiplying the speed by a friction coefficient and multiplying that by delta time 
sed into the 

ApplyFriction method in order to manipulate the velocity. 

Finally, the change in position, called deltaPos is calculated by multiplying the 
velocity by delta time, and is passed into the Move method to adjust the entity's 
position in the world. The flags for collisions on both axes get reset to false and the 
entity calls its own private members for first obtaining and then resolving collisions. 

Let's take a look at the method responsible for updating the bounding box: 

void EntityBase : : UpdateAABB ( ) { 

m_AABB = sf : : FloatRect (m_position . x - (m_size.x / 2), 
m_position.y - m_size.y, m_size.x, m_size.y); 

} 

Because the origin of the bounding box is left at the top-left corner and the entity's 
ry if we want 
box is reset 

to match the new position of the sprite. 

Entity-on-tile collisions 

e method SFML 

provides to check if two rectangles are intersecting: 

sf :: FloatRect rl; 
sf :: FloatRect r2; 
if (rl . intersects (r2 )) { ... } 

still return 

true if they are intersecting. However, this method does take in an optional second 
argument, which is a reference of a rectangle class that will be filled with the 
ration: 
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represents 

the rectangle of intersection, which can be obtained by doing this: 

sf : : FloatRect intersection; 

if (rl . intersects (r2 , intersection) ) { ... } 

than one tile 
solving it. With 

that in mind, let's define a structure to temporarily hold the collision information 
before it gets resolved: 

struct CollisionElement { 

CollisionElement (float l_area, Tilelnfo* l_info, 
const sf : :FloatRect& l_bounds) : m_area ( l_area) , 
m_tile (l_info) , m_tileBounds (l_bounds) { } 
float m_area; 

Tilelnfo* m_tile; 

sf :: FloatRect m_tileBounds ; 

} ; 


using Collisions = std : : vector<CollisionElement> ; 

First, we're creating a structure that holds a floating point number representing the 
tile the entity's 

colliding with, and a pointer toaTileinfo instance. You always want to resolve 
the biggest collisions first, and this information is going to help us do just that. The 
me. 
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tainer 

in order to sort it, the blueprint of which in the header file of the EntityBase class 
looks like this: 

bool SortCollisions (const CollisionElement& 1_1, 
const CollisionElement& 1 2 ) ; 

ly uses a 
is larger, 
e we're 
he first 

elements of the first pairs: 

bool SortCollisions (const CollisionElement& 1_1, 
const CollisionElement& 1_2) 

{ return l_l.m_area > l_2.m_area; } 

Now onto the interesting part, detecting the collisions: 

void EntityBase: : CheckCollisions ( ) { 

Map* gameMap = m_entityManager- >GetContext ( ) - >m_gameMap ; 

unsigned int tileSize = gameMap- >GetTileSize () ; 

int fromX = floor (m_AABB . left / tileSize); 

int toX = f loor ( (m_AABB . lef t + m_AABB . width) / tileSize); 

int fromY = floor (nW\ABB . top / tileSize); 

int toY = floor ( (m_AABB . top + m_AABB . height ) / tileSize); 

for(int x = fromX; x <= toX; ++x) { 
for(int y = fromY; y <= toY; ++y) { 

Tile* tile = gameMap- >GetTile (x, y) ; 
if ( ! tile) { continue; } 

sf : : FloatRect tileBounds (x * tileSize, y * tileSize, 
tileSize , tileSize) ; 
sf :: FloatRect intersection; 

m_AABB . intersects (tileBounds , intersection) ; 

float area = intersection . width * intersection . height ; 

CollisionElement e (area, tile- >m_properties , tileBounds); 
m_collisions . emplace_back (e) ; 

if (tile->m_warp && m_type == EntityType :: Player ) { 
gameMap- >LoadNext () ; 

} ’ 

} 

} 

} 
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We begin by using the coordinates and size of the bounding box to obtain the 
better in the 
following image: 
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ed into a 

double loop which checks if there is a tile occupying the space we're interested in. If a 
tile is returned from the GetTile method, the bounding box of the entity is definitely 
intersecting a tile, so a float rectangle that represents the bounding box of a tile is 
created. We also prepare another float rectangle to hold the data of the intersection 
and call the intersects method in order to obtain this information. The area of the 
information 
pointer to the 

Tilelnf o object that represents the type of tile the entity is colliding with, 
ent tile the 

entity is colliding with is a warp tile and if the entity is a player. If both of these 
conditions are met, the next map is loaded. 

them is the 
next step: 

void EntityBase: : ResolveCollisions ( ) { 
if ( ! m_collisions . empty ( ) ) { 

std: : sort (m_collisions .begin ( ) , 

m_collisions . end ( ) , SortCollisions) ; 

Map* gameMap = m_entityManager- >GetContext ( ) - >m_gameMap ; 
unsigned int tileSize = gameMap- >GetTileSize () ; 
for (auto &itr : m_collisions ) { 

if (! m_AABB . intersects ( itr . m_tileBounds )) { continue; } 
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float xDiff = (m_AABB.left + (m_AABB . width / 2) ) - 

( itr . m_tileBounds . lef t + ( itr . m_tileBounds . width / 2) ) ; 
float yDiff = (m_AABB . top + (m_AABB . height / 2) ) - 

( itr . m_tileBounds . top + ( itr . m_tileBounds . height / 2) ) ; 
float resolve = 0; 
if (abs (xDiff ) > abs (yDiff) ){ 
if (xDiff > 0 ) { 

resolve = ( itr . m_tileBounds . lef t + tileSize) - 
m_AABB .left; 

} else { 

resolve = - ( (m_AABB . left + m_AABB . width) - 
itr . m_tileBounds . lef t ) ; 

} 

Move (resolve , 0) ; 
m_velocity.x = 0; 
m_collidingOnX = true; 

} else { 

if (yDiff > 0) { 

resolve = ( itr . m_tileBounds . top + tileSize) - 
m_AABB . top ; 

} else { 

resolve = - ( (nW\ABB . top + m_AABB . height) - 

itr . m_tileBounds . top) ; 

} 

Move ( 0 , resolve) ; 
m_velocity.y = 0; 
if (m_collidingOnY) { continue; } 
m_ref erenceTile = itr. motile ; 
m_collidingOnY = true; 

} 

} 

m_collisions . clear ( ) ; 

} 

if ( !rn_collidingOnY) { m_ref erenceTile = nullptr; } 

} 

all the elements 

happens next. The std : : sort function is called and iterators to the beginning and 
that will do 

the comparisons between the elements. 
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The code proceeds to loop over all of the collisions stored in the container. There is 
another intersection check here between the bounding box of the entity and the tile. 
This is done because resolving a previous collision could have moved an entity in 
such a way that it is no longer colliding with the next tile in the container. If there 
still is a collision, distances from the center of the entity's bounding box to the center 
of the tile's bounding box are calculated. The first purpose these distances serve is 
illustrated in the next line, where their absolute values get compared. If the distance 
on the x axis is bigger than on the y axis, the resolution takes place on the x axis. 
Otherwise, it's resolved on the y axis. 

The second purpose of the distance calculation is determining which side of the tile 
the entity is on. If the distance is positive, the entity is on the right side of the tile, so 
he negative x 

direction. The resolve variable takes in the amount of penetration between the tile and 
lision. 

In the case of both axes, the entity is moved by calling its Move method and passing 
in the depth of penetration. Killing the entity's velocity on that axis is also important, 
in order to simulate the entity hitting a solid. Lastly, the flag for a collision on a 
specific axis is set to true. 

If a collision is resolved on the y axis, in addition to all the same steps that are taken 
in a case of x axis collision resolution, we also check if the flag is set for a y axis 
collision. If it hasn't been set yet, we change the m_ref erenceTile data member to 
point to the tile type of the current tile the entity is colliding with, which is followed 
by that flag getting set to true in order to keep the reference unchanged until the next 
time collisions are checked. This little snippet of code gives any entity the ability to 
behave differently based on which tile it's standing on. For example, the entity can 
slide a lot more on ice tiles than on simple grass tiles, as illustrated here: 
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As the arrow points out, the friction coefficient of these tiles is different, which 
elow. 

Entity storage and management 

red about 
to create 

interactions between entities, they need to be babysat by a manager class. Before 
we begin designing it, let's define some data types to contain the information we're 
going to be working with: 

using EntityContainer = std: : unordered_map< 
unsigned int , EntityBase*> ; 
using EntityFactory = std: : unordered_map< 

EntityType, std: : function<EntityBase* (void) >> ; 
using EnemyTypes = std :: unordered_map<std :: string, std :: string> ; 

The EntityContainer type is, as the name suggests, a container of entities. It is once 
again powered by an unordered_map, which ties instances of entities to unsigned 
integers that serve as identifiers. The next type is a container of lambda functions that 
of classes 

that inherit from the base entity class and serves as a factory. This behavior isn't new 
to us, so let's move on to defining the entity manager class: 

class EntityManager { 
public : 

EntityManager (SharedContext* l_context , 
unsigned int l_maxEntities) ; 

-EntityManager ( ) ; 

int Add (const EntityTypek l_type, 
const std::string& l_name = 

EntityBase* Find (unsigned int l_id) ; 

EntityBase* Find(const std : : strings l_name) ; 
void Remove (unsigned int l_id) ; 

void Update (float l_dT) ; 
void Draw ( ) ; 

void Purge ( ) ; 

SharedContext* GetContext ( ) ; 
private : 

template<class T> 
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void RegisterEntity (const EntityType& l_type) { 

m_entityFactory [l_type] = [this] () -> EntityBase* 

{ 

return new T(this) ; 



void ProcessRemovals ( ) ; 

void LoadEnemyTypes (const std::string& l_name) ; 
void EntityCollisionCheck ( ) ; 

EntityContainer m_entities; 

EnemyTypes m_enemyTypes ; 

EntityFactory m_entityFactory ; 

SharedContext* m_context ; 
unsigned int m_idCounter; 
unsigned int m_maxEntities ; 

std: :vector<unsigned int> m_entitiesToRemove ; 

} ; 


to the 

entity factory container, this looks like a relatively typical class. We have methods 
for updating and drawing entities, adding, finding and removing them and 
ethod called 

ProcessRemovals insists that we're using delayed removals of entities, much like 
we did in our state manager class. Let's take a closer look at how this class will 
operate by implementing it. 

Implementing the entity manager 

As always, a good place to start is the constructor: 

EntityManager : : EntityManager (SharedContext* l_context, 
unsigned int l_maxEntities) :m_context (l_context) , 
m_maxEntities (l_maxEntities ) , m_idCounter ( 0 ) 

{ 

LoadEnemyTypes ( "EnemyList . list" ) ; 

RegisterEntity<Player> (EntityType : : Player) ; 
RegisterEntity<Enemy> (EntityType : : Enemy) ; 

} 

EntityManager :: -EntityManager () { Purge () ; } 
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e m_idCounter 

variable will be used to keep track of the highest ID that was given to an entity. Next, 
a private method is invoked for loading pairs of enemy names and their character 
definition files, which will be explained a little later. 

Lastly, two entity types are registered: player and enemy. We don't have their classes 
set up yet, but it's coming soon, so we may as well just register them now. 

The destructor of an entity manager simply invokes the Purge method. 

Adding a new entity to the game is done by passing in an entity type along with its 
name to the Add method of the entity manager: 

int EntityManager :: Add (const EntityTypek l_type, 
const std: : string& l_name) 

{ 

auto itr = m_entityFactory . f ind (l_type) ; 
if (itr == m_entityFactory . end ( ) ) { return -1; } 

EntityBase* entity = itr- >second ( ) ; 
entity- >m_id = m idCounter; 

if (l_name != ""){ entity- >m_name = l_name; } 
m_entities . emplace (m_idCounter , entity) ; 
if (l_type == EntityType: : Enemy) { 

auto itr = m_enemyTypes . f ind (l_name) ; 
if (itr != m_enemyTypes . end ( ) ) { 

Enemy* enemy = (Enemy* ) entity ; 
enemy- >Load ( itr- >second) ; 

} 

} 


++m_idCounter ; 

return m_idCounter - 1; 

} 

as an 

argument. If that type is registered, the lambda function is invoked to allocate 
dynamic memory for the entity and the memory address is caught by a pointer 
variable to the EntityBase class - entity. The newly created entity is then inserted 
into the entity container and its ID is set up by using the m idcounter data member, 
well. 

The entity type then gets checked. If it's an enemy, the enemy type container is 
searched in order to locate the path to a character definition file. If it's found, the 
entity is type-cast into an enemy instance and a Load method is called, to which 
the character file path is passed. 
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ed gets 

instead return -1, 
signifying a failure. 

Having an entity manager is pointless if you can't obtain the entities. That's where 
the Find method comes in: 

EntityBase* EntityManager :: Find ( const std : : strings l_name) { 
for (auto &itr : m_entities) { 

if ( itr . second- >GetName ( ) == l_name) { 
return itr. second; 

} 

} 

return nullptr; 

} 

Our entity manager provides two versions of this method. The first version takes in 
an entity name and searches the container until an entity is found with that name, 
sed on a 

numerical identifier: 

EntityBase* EntityManager :: Find (unsigned int l_id) { 
auto itr = identities . f ind (l_id) ; 
if (itr == identities . end ( ) ) { return nullptr; } 
return itr->second; 

} 

Because we map instances of entities to numerical values, this is easier, as we can 
simply call the Find method of our container in order to find the element we're 
looking for. 

Now let's work on removing entities: 

void EntityManager :: Remove (unsigned int l_id) { 
m_entitiesToRemove . emplace_back ( l_id) ; 

} 

a container, 

which will be used later to remove entities. 

Updating all entities can be achieved as follows: 

void EntityManager :: Update ( float l_dT) { 
for(auto &itr : identities) { 
itr . second- >Update (l_dT) ; 

} 
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EntityCollisionCheck ( ) ; 

ProcessRemovals () ; 

} 

ctive Update 

11 of the 

entities are updated, a private method EntityCollisionCheck is invoked in order 
to check for and resolve collisions between entities. Then, we process the entity 
removals that were added by the Remove method implemented previously. 

Let's take a look at how we can draw all of these entities: 

void EntityManager : : Draw ( ) { 

sf : : RenderWindow* wnd = m__context->m_wind->GetRenderWindow ( ) ; 
sf : : FloatRect viewSpace = m_context->m_wind->GetViewSpace ( ) ; 

for (auto &itr : m_entities) { 

if (! viewSpace . intersects ( itr . second- >m_AABB) ) { continue; } 
itr . second- >Draw (wnd) ; 

} 

} 

After obtaining a pointer to the render window, we also get the view space of it in 
order to cull entities for efficiency reasons. Because both the view space and the 
bounding box of an entity are rectangles, we can simply check if they're intersecting 
s, it gets drawn. 

es. This is 

where the Purge method comes in: 

void EntityManager :: Purge () { 
for (auto &itr : m_entities) { 
delete itr. second; 

} 

m_entities . clear ( ) ; 
m_idCounter = 0; 

} 

regular as 

clockwork. Now to process the entities that need to be removed: 

void EntityManager: : ProcessRemovals ( ) { 

while (m_entitiesToRemove . begin ( ) != m_entitiesToRemove . end ( ) ) { 

unsigned int id = m_entitiesToRemove . back ( ) ; 
auto itr = m_entities . f ind (id) ; 
if (itr != identities . end ( ) ) { 
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std::cout << "Discarding entity: " 

<< itr- >second- >GetId ( ) << std::endl; 
delete itr->second; 
m_entities . erase (itr) ; 

} 

m_entitiesToRemove .pop_back ( ) ; 

} 


t need to be 
hat was 
ocated and 

the element is popped from the entity container. 

Now for the interesting part - detecting entity -to-entity collisions: 

void EntityManager : : EntityCollisionCheck ( ) { 
if (m_entities . empty ()) { return; } 
for (auto itr = m_entities . begin () ; 

std :: next ( itr ) != m_entities . end ( ) ; ++itr) 

{ 

for (auto itr2 = std: : next ( itr) ; 
itr2 != m entities . end () ; ++itr2) 

{ 

if ( itr- >f irst == itr2->first) { continue; } 

// Regular AABB bounding box collision. 

if (itr- >second- >m_AABB . intersects ( itr2 - >second- >m_AABB) ) { 
itr- >second- >OnEntityCollision ( itr2 - >second, false) ; 
itr2 - >second- >OnEntityCollision ( itr- >second, false) ; 

} 

EntityType tl = itr- >second- >GetType ( ) ; 

EntityType t2 = itr2 - >second- >GetType ( ) ; 

if (tl == EntityType :: Player | | tl == EntityType :: Enemy) { 
Character* cl = (Character* ) itr- >second; 
if (cl- >m_attackAABB . intersects ( itr2 - > second- >m_AABB) ) { 
cl- >OnEntityCollision ( itr2 - >second, true) ; 

} 

} 


if (t2 == EntityType :: Player | | t2 == EntityType :: Enemy) { 
Character* c2 = (Character* ) itr2 - >second; 
if (c2 - >m_attackAABB . intersects ( itr- >second- >m_AABB) ) { 
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c2->0nEntityCollision(itr->second, true) ; 

} 

} 

} 

} 

} 

First, the way we're checking every entity against every other entity needs to be 
addressed. There are, of course, much better and more efficient ways to determine 
as binary 
be overkill: 

" Premature optimization is the root of all evil (or at least most of it) in 
programming . " 

- Donald Knuth 

Having said that, we are going to be a bit smarter and not simply iterate over all of 
the entities twice. Because checking entity 0 against entity 1 is the same as checking 
entity 1 against 0, we can implement a much more efficient algorithm by using 
std : : next, 

and use it in the second loop. This creates a check pattern that looks something 
like this: 











0 

1 

2 

3 

4 


ing a game. 

When iterating over entities, the collision check method first makes sure that both 
iterators do not share the same entity ID, for some odd reason. Then, it's simply a 
matter of checking for intersections between the bounding boxes of the two entities 
t are called in 

both instances, passing in the entity being collided with as an argument, along with 
collision. 

What does that mean? Well, generally, there are going to be two types of collisions 
between entities: regular bounding box collisions and attack collisions. Children of 
the EntityBase class, mainly the Character instances, will have to keep another 
bounding box in order to perform attacks, as illustrated here: 
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0 512 

I: 0 0.713210 
check; 0 0.713216 
1024 
; 0.8 0 
1.14115 0 
on: 0 0.713216 
5 800 
.5 800.001 
00090351 


plementing 

the entity manger until we implement the Character class shortly. 

Since only the Character class and any class that inherits from it is going to have an 
attack bounding box, it's necessary to first check if we're dealing with a character 
instance by verifying the entity type. If an entity is of the type Enemy or Player, the 
OnEntityCollision method of the Character instance is invoked and receives 
the entity it's colliding with, as well as a Boolean constant of true this time, as 
arguments, to indicate an attack collision. 

pes that can 
parse files like this: 

| Name | CharFile | 

Rat Rat . char 


[ 187 ] 


Rediscovering Fire - Common Game Design Elements 

It's quite a simple format. Let's read it in: 

void EntityManager :: LoadEnemyTypes (const std : : strings l_name) { 
std: : if stream file; 

... // Opening the file, 
while ( std : : get line ( f ile , line) ) { 
if (line[0] == 1 | 1 ) { continue; } 
std: : stringstream keystream ( line) ; 
std:: string name; 
std:: string charFile; 
keystream >> name >> charFile; 
m_enemyTypes . emplace (name, charFile) ; 

} 

file . close ( ) ; 

} 

read in and 
r interest in 

the entity manager class. 

Using entities to build characters 

So far, we only have entities that define some abstract methods and provide the 
means of manipulating them, but nothing that can appear in the game world, be 
nt all of 

that functionality all over again in the player or enemy classes, which means we need 
an intermediate-level abstract class: character. This class will provide all of the 
functionality that is shared between all entities that need to move around the world 
and be rendered. Let's get on with designing: 

class Character : public EntityBase{ 
friend class EntityManager; 
public : 

Character (EntityManager* l_entityMgr) ; 

virtual -Character () ; 

void Move (const Directions: l_dir) ; 

void Jump ( ) ; 

void Attack ( ) ; 

void GetHurt (const int& l_damage) ; 
void Load (const std:: strings l_path) ; 
virtual void OnEntityCollision ( 

EntityBase* l_collider, bool l_attack) = 0; 
virtual void Update (float l_dT) ; 
void Draw (sf : : RenderWindow* l_wind) ; 


[ 188 ] 



Chapter 7 


protected : 

void UpdateAttackAABB ( ) ; 
void Animate ( ) ; 

SpriteSheet m_spriteSheet ; 
float m_jumpVelocity; 
int m_hitpoints; 
sf : : FloatRect m_attackAABB ; 
sf::Vector2f m_attackAABBof f set ; 

}; 

and receiving 

damage are the common actions of every character-entity in the game. The character 
nd properties 

that differ between each enemy type and the player. All classes derived from it have 
s. Also, 

the Update method of the character class is made to be virtual, which allows any 
class inheriting from this one to either define its own update method or extend the 
existing one. 

viously in 

order to support animations. 

Implementing the character class 

You know the drill by now. Here's the constructor: 

Character: : Character (EntityManager* l_entityMgr) 

: EntityBase (l_entityMgr) , 

m_spriteSheet (m_entityManager- >GetContext () - >m_textureManager ) , 
m_jumpVelocity (250) , m_hitpoints ( 5 ) 

{ m_name = "Character"; } 

The sprite sheet is created and set up by passing a pointer to the texture manager in 
its constructor. We also have a data member called m_jumpVelocity, which specifies 

m_hitpoints 

variable, which represents how many times an entity can be hit before it dies. 

Let's move on to the Move method: 

void Character :: Move (const Directions: l_dir) { 

if (GetStateO == EntityState :: Dying) { return; } 
m_spriteSheet . SetDirection (l_dir) ; 

if (l_dir == Direction :: Left) { Accelerate ( -m_speed . x, 0); } 
else { Accelerate (m_speed . x, 0); } 
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if (GetStateO == EntityState : : Idle) { 

SetState (EntityState : :Walking) ; 

} 

} 

Regardless of the entity's direction, the state of the entity is checked in order to make 
sure the entity isn't dying. If it isn't, the direction of the sprite sheet is set up and the 
character begins to accelerate on a relevant axis. Lastly, if the entity is currently in an 
idle state, it gets set to walking simply to play the walking animation: 

void Character :: Jump () { 

if (GetStateO == EntityState :: Dying | | 

GetStateO == EntityState :: Jumping | | 

GetStateO == EntityState :: Hurt ) 

{ 

return; 

} 

SetState (EntityState : : Jumping) ; 

AddVelocity ( 0 , -m_jumpVelocity) ; 

} 

, or jumping 
o jump, its 

state is set to Jumping and it receives negative velocity on the y axis that makes it 
n order to 

break the gravitational force of the level, 
does the 

entity isn't dying, 

jumping, taking damage, or already attacking: 

void Character :: Attack () { 

if (GetStateO == EntityState :: Dying | j 
GetStateO == EntityState :: Jumping | j 
GetStateO == EntityState Hurt || 

GetStateO == EntityState :: Attacking) 

{ 

return; 

} 

SetState (EntityState : : Attacking) ; 

} 
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In order to bestow mortality onto our entities, they need to have a way to be hurt: 

void Character :: GetHurt (const int& l_damage) { 
if (GetStateO == EntityState :: Dying || 

GetStateO == EntityState: : Hurt) 

{ 

return; 

} 

m_hitpoints = (m_hitpoints - l_damage > 0 ? 

m_hitpoints - l_damage : 0) ; 
if (m_hitpoints) { SetState (EntityState :: Hurt) ; } 
else { SetState (EntityState :: Dying) ; } 

} 

This method inflicts damage to the character if it isn't already taking damage or 
hitpoints 

variable is set to 0 in order to keep it from reaching the negatives. If the entity still 
has lives after the subtraction, its state is set to hurt in order to play the proper 
animation. Otherwise, the entity is sentenced to death by the programmer. 

om files like 

this one (Player . char): 

Name Player 

Spritesheet Player. sheet 
Hitpoints 5 
BoundingBox 20 26 
DamageBox -5 0 26 26 
Speed 1024 128 
JumpVelocity 250 
MaxVelocity 200 1024 

like the sprite 

sheet handle and all of the other information discussed in earlier sections. The 
loading method for this type of file will not differ much from the ones we've 
already implemented: 

void Character :: Load (const std::string& l_path) { 
std: : if stream file; 

while ( std : : get line ( f ile , line) ) { 

std:: string type; 
keystream >> type; 
if (type == "Name"){ 
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keystream >> m_name; 

} else if (type == " Spritesheet " ) { 
std::string path; 
keystream >> path; 

m_spriteSheet . LoadSheet ( "media/SpriteSheets/ " + path); 

} else if (type == "Hitpoints " ) { 
keystream >> m_hitpoints; 

} else if (type == "BoundingBox" ) { 
sf::Vector2f boundingSize; 

keystream >> boundingSize . x >> boundingSize .y; 

SetSize (boundingSize .x, boundingSize . y) ; 

} else if (type == "DamageBox" ) { 

keystream >> m_attackAABBof fset .x >> m_attackAABBof fset .y 
>> m_attackAABB . width >> m_attackAABB . height ; 

} else if (type == "Speed") { 

keystream >> m_speed.x >> m_speed.y; 

} else if (type == " JumpVelocity" ) { 
keystream >> m_jumpVelocity ; 

} else if (type == "MaxVelocity" ) { 

keystream >> m_maxVelocity . x >> m_maxVelocity .y; 

} else { 

std::cout << "! Unknown type in character file: " 

<< type << std::endl; 

} 

} 

file . close ( ) ; 

} 

mply loading in 

data members from a string stream. 

Just like the base entity and its bounding box, the character has to have a way to 
update the position of its attack area: 

void Character: : UpdateAttackAABB ( ) { 
m__attackAABB . lef t = 

(m_spriteSheet . GetDirection ( ) == Direction :: Lef t ? 

(m_AABB.left - m_attackAABB . width) - m_attackAABBof fset .x 
: (m_AABB.left + m_AABB . width) + m_attackAABBof fset .x) ; 
m__attackAABB . top = m_AABB . top + m_attackAABBof f set .y; 

} 

One subtle difference here is that the attack bounding box uses the position of the 
entity's bounding box, not its sprite position. Also, the way it's positioned is different 
based on the direction an entity is facing, due to the fact that the bounding box’s 
position represents its top-left corner. 
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mg: 

void Character :: Animate () { 

EntityState state = GetStateO; 

if (state == EntityState :: Walking && m_spriteSheet . 

GetCurrentAnim ( ) - >GetName ( ) != "Walk") 

{ 

m_spriteSheet . SetAnimation ( "Walk" , true , true) ; 

} 

else if (state == EntityState :: Jumping && m_spriteSheet . 
GetCurrentAnim ()- >GetName ( ) != "Jump") 

{ 

m_spriteSheet . SetAnimation ( "Jump" , true , false) ; 

} 

else if (state == EntityState :: Attacking && m_spriteSheet . 
GetCurrentAnim ()- >GetName ( ) != "Attack") 

{ 

m_spriteSheet . SetAnimation ( "Attack" , true , false) ; 

} else if (state == EntityState :: Hurt && m_spriteSheet . 
GetCurrentAnim ()- >GetName ( ) != "Hurt") 

{ 

m_spriteSheet . SetAnimation ( "Hurt " , true , false) ; 

} 

else if (state == EntityState :: Dying && m_spriteSheet . 

GetCurrentAnim ()- >GetName ( ) != "Death") 

{ 

m_spriteSheet . SetAnimation ( "Death" , true, false) ; 

} 

else if (state == EntityState :: Idle && m_spriteSheet . 

GetCurrentAnim ()- >GetName ( ) != "Idle") 

{ 

m_spriteSheet . SetAnimation ( " Idle " , true , true) ; 

} 

} 

If the current 
e. Note the use 

of the third argument in the SetAnimation method, which is a Boolean constant and 
ke the attack 
hey reach 
mply 

based on the progress of a certain animation. Case in point - the Update method: 

void Character :: Update ( float l_dT) { 

EntityBase: : Update ( l_dT) ; 

if (m_attackAABB . width != 0 && m_attackAABB . height != 0) { 
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UpdateAttackAABB ( ) ; 

} 

if (GetState ( ) != EntityState :: Dying && GetStateO != 

EntityState :: Attacking && GetStateO != EntityState :: Hurt ) 

{ 

if (abs (m_velocity .y) >= 0.001f){ 

SetState (EntityState : : Jumping) ; 

} else if (abs (m_velocity .x) >= 0.1f){ 

SetState (EntityState : : Walking) ; 

} else { 

SetState (EntityState : :Idle) ; 

} 

} else if (GetState ( ) == EntityState :: Attacking || 

GetStateO == EntityState :: Hurt ) 

{ 

if ( ! m_spriteSheet . Ge t Cur rent Anim ( ) - > I sPlaying 0 ) { 

SetState (EntityState : :Idle) ; 

} 

} else if (GetStateO == EntityState :: Dying) { 

if ( !m_spriteSheet . GetCurrentAnim ( ) - >IsPlaying 0 ) { 
m_entityManager- >Remove (m_id) ; 

} 

} 

Animate ( ) ; 

m_spriteSheet . Update ( l_dT) ; 

m_spriteSheet . SetSpritePosition (m_position) ; 

} 

First, we invoke the update method of the entity's base class, because the character's 
k bounding 

box aren't still at 0, which are the default values for them. If they aren't, it means 
the attack bounding box has been set up and can be updated. The rest of the 
isn't dying, 

attacking something, or taking damage, its current state is going to be determined 
by its velocity. In order to accurately depict an entity falling, we have to make the 
velocity on y axis take precedence over everything else. If the entity has no vertical 
e to Walking 

if the velocity is higher than the specified minimum. Using small values instead of 
imes. 

sprite sheet 
, the state is switched 

back to idle. Lastly, if the entity is dying and the dying animation is finished playing, 
we call the Remove method of our entity manager in order to remove this entity from 
the world. 
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The Animate method is called near the end of the update in order to reflect the state 
gets updated 

and has its position set to match the position of the entity. 

After all of that code, let's end on something really simple - the Draw method: 

void Character :: Draw ( sf :: RenderWindow* l_wind) { 
m_spriteSheet . Draw ( l_wind) ; 

} 

Since our sprite-sheet class takes care of drawing, all we need to do is pass a pointer 
of a render window to its Draw method. 

Creating the player 

nted on 

screen. Let's put that to good use and finally build our player class by starting 
with the header: 

class Player : public Character! 
public : 

Player (EntityManager* l_entityMgr) ; 

-Player ( ) ; 

void OnEntityCollision (EntityBase* l_collider, bool l_attack) ; 
void React (EventDetails* l_details) ; 

} ; 

This is where things get easy. Because we essentially "outsourced" most of the 
yer-specific 

logic. Notice the React method. Judging by its argument list, it's obvious that we're 
going to be using it as a callback for handling player input. Before we do that, 
however, we must register this method as one: 

Player: : Player (EntityManager* l_entityMgr) 

: Character (l_entityMgr) 

{ 

Load (" Player . char " ) ; 
m__type = EntityType :: Player ; 

EventManager* events = m_entityManager- > 

GetContext ( ) - >m_eventManager ; 
events- >AddCallback< Player > (StateType : : Game , 

" Player_MoveLef t " , &Player :: React , this); 
events- >AddCallback< Player > (StateType : : Game , 
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" Player_MoveRight " , &Player :: React , this); 
events- >AddCallback< Player > (StateType : : Game , 

" Player_Jump" , &Player :: React , this); 
events- >AddCallback< Player > (StateType : : Game , 

" Player_Attack" , &Player :: React , this); 

} 

All we're doing here is calling the Load method in order to set up the character 
values for our player and adding multiple callbacks to the same React method that 
will be used to process keyboard input. The type of the entity is also set to Player: 

Player: : -Player () { 

EventManager* events = 

m_entityManager- >GetContext () ->m_eventManager; 
events- >RemoveCallback (GAME , " Player_MoveLef t " ) ; 
events- >RemoveCallback (GAME , " Player_MoveRight " ) ; 
events- >RemoveCallback (GAME , "Player_Jump" ) ; 
events- >RemoveCallback (GAME , " Player_Attack" ) ; 

} 

e using 

to move the player around. 

The last method we are required to implement by the character class is responsible 
for entity-on-entity collision: 

void Player :: OnEntityCollision (EntityBase* l_collider, 
bool l_attack) 

{ 

if (m__state == EntityState :: Dying) { return; } 
if (l_attack) { 

if (m_state != EntityState :: Attacking) { return; } 
if ( ! m_spriteSheet . GetCurrentAnim ( ) - >IsInAction ( ) ) { return; } 
if (l_collider- >GetType ( ) != EntityType :: Enemy && 

l_collider- >GetType ( ) != EntityType :: Player ) 

{ 

return; 

} 

Character* opponent = (Character* ) ^collider- 
opponent- >GetHurt ( 1 ) ; 

if (m_position . x > opponent- >GetPosition (). x) { 
opponent- >AddVelocity (-32, 0) ; 

} else { 

opponent- >AddVelocity (32 , 0 ) ; 

} 
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} else { 

// Other behavior. 

} 

} 


This method, as you remember from the entity manager portion of this chapter, 
case of 
s method 

together with a flag to determine if the entity is colliding with your bounding 
box or your attack region. 

First, we make sure the player entity isn't dying. Afterwards, we check if it's the 
attack region that is colliding with another entity. If it is and the player is in the 
attack state, we check if the attack animation in the sprite sheet is currently "in 
action." If the current frame is within range of the beginning and end frames when 
the entity 

is either a player or an enemy. Finally, if it is one or the other, the opponent gets 
ave some 
me design 
as it gets. 

Adding enemies 

d, we must 

add enemies to the game. Once again, let's begin with the header file: 

#pragma once 
#include "Character . h" 


class Enemy : public Character{ 
public : 

Enemy (EntityManager* l_entityMgr) ; 

-Enemy ( ) ; 

void OnEntityCollision ( 

EntityBase* l_collider, bool l_attack) ; 
void Update (float l_dT) ; 
private : 

sf::Vector2f m_destination; 
bool m_hasDestination; 

} ; 
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however, the 

enemy class needs to specify its own version of the Update method. It also has 
very simple 

attempt at adding basic artificial intelligence to the game. All it will do is keep track 
of a destination position, which the Update method will randomize every now and 
then to simulate wandering entities. Let's implement this: 

Enemy: : Enemy (EntityManager* l_entityMgr) 

: Character ( l_entityMgr) , m_hasDestination (false) 

{ 

m_type = EntityType :: Enemy ; 

} 

Enemy : : -Enemy ( ) { } 

alues, while 

the destructor remains unused. So far, so good! 

void Enemy : :OnEntityCollision (EntityBase* l_collider, 
bool l_attack) 

{ 

if (m_state == EntityState :: Dying) { return; } 
if (l_attack) { return; } 

if (l_collider- >GetType ( ) != EntityType :: Player ) { return; } 

Character* player = (Character* ) l_collider ; 

SetState (EntityState : :Attacking) ; 
player- >GetHurt (1); 

if (m_position . x > player- >GetPosition (). x) { 
player- >AddVelocity ( -m_speed . x, 0 ) ; 
m_spriteSheet . SetDirection (Direction : :Left) ; 

} else { 

player- >AddVelocity(m_speed.y, 0) ; 
m_spriteSheet . SetDirection (Direction : :Right) ; 

} 

} 

we make sure to 

act if the enemy's bounding box is colliding with another entity, not its attack region. 
Also, we ignore every single collision, unless it's colliding with a player entity, 
in which case the enemy's state is set to Attacking in order to display the attack 
animation. It inflicts damage of 1 point to the player and knocks them back just a 
little bit based on where the entity is. The sprite-sheet direction is also set based on 
the position of the enemy entity relative to what it's attacking. 
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Now, to update our enemy: 

void Enemy :: Update ( float l_dT) { 

Character: : Update (l_dT) ; 

if (m_hasDestination) { 

if (abs (m_destination . x - m position.x) < 16) { 
npJiasDestination = false; 
return; 

} 

if (m_destination . x - m position.x > 0) { 

Move (Direction : : Right) ; 

} else { Move (Direction :: Left ) ; } 

if (m_collidingOnX) { m_hasDestination = false; } 

return; 

} 

int random = rand() % 1000 + 1; 

if (random != 1000) { return; } 

int newX = rand() % 65 + 0; 

if ( rand ( ) % 2) { newX = -newX; } 

m_destination . x = m position.x + newX; 

if (npjdestination . x < 0) { m_destination . x = 0; } 

m__hasDestination = true; 

} 

Because this depends on the functionality of the Character class, we invoke 

its update method first before doing anything. Then the most basic simulation 

of A.I. begins by first checking if the entity has a destination. If it does not, a 

have 

tion. The 

aller 

this time. The destination finally is set and gets checked for being outside the world 
boundaries. 

between it and 
od for moving 

in a specific direction is called, based on which direction the destination point is in. 
We must also check for horizontal collisions, because an enemy entity could easily 
happens, the 

destination is simply taken away. 

With that done, we now have wandering entities and a player that can be moved 
hese entities 

into the game now is to load them. 
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Loading entities from the map file 

of creating a 

map class, we haven't finished implementing the loading method fully, because we 
had no entities yet. With that no longer being the case, let's take a look at extending 
it: 


} else if (type == "PLAYER") { 

if (playerld != -1) { continue; } 

// Set up the player position here. 

playerld = entityMgr- >Add (EntityType :: Player) ; 

if (playerld < 0) { continue; } 

float playerX = 0; float playerY = 0; 

keystream >> playerX >> playerY; 

entityMgr- >Find (playerld) - >SetPosition (playerX, playerY) ; 
m_playerStart = sf : :Vector2f (playerX, playerY); 

} else if (type == "ENEMY") { 
std: : string enemyName; 
keystream >> enemyName; 

int enemyld = entityMgr- >Add (EntityType :: Enemy, enemyName); 
if (enemyld < 0) { continue; } 
float enemyX = 0; float enemyY = 0; 
keystream >> enemyX >> enemyY; 

entityMgr- >Find (enemyld) - >SetPosition (enemyX, enemyY) ; 

} ... 

If the map encounters a player line, it simply attempts to add an entity of type 
P 1 aye r successful, 

meaning that we can read in the rest of the data from the map file, which happens to 
be the player position. After obtaining it, we set the player's position and make sure 
we keep track of the starting position in the map class itself too. 

All of the above is true for the enemy line as well, except it also loads in the name of 
rom the file. 
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Now our game is capable of loading entities from the map files and thus putting 
them into the game world like so: 


Velocity after friction: 0 0.70144 
Old position: 40.8682 800 
New position: 40.8682 800.001 
Delta position: 0 0.000960973 


F 


id: 0 





I 



Final editions to our code base 

nd additions/ 

hapters in 

now moved 

into its own header file. 

Changes to the shared context 

Out of all of the extra classes we defined, some of them need to be accessible to the 
ike now: 

class Map; 

struct SharedContext{ 

SharedContext () : 
m_wind (nullptr) , 
m_eventManager (nullptr ) , 
m_textureManager (nullptr ) , 
m_entityManager (nullptr ) , 
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m_gameMap (nullptr) { } 

Window* m_wind; 

EventManager* m_eventManager ; 
TextureManager* m_t extureManager ; 
EntityManager* m_entityManager ; 
Map* m_gameMap; 

DebugOverlay m_debugOverlay ; 

} ; 


The last object in it is the debug overlay we briefly discussed while working on 

providing 

pike tiles, giving 

e the debug 

ded here, but 

they're present in the code that comes with it. 

Putting all the pieces together 

ight places, 

starting with the entity manager class, which goes straight into the game class as a 
data member: 

class Game{ 
public : 


private : 

EntityManager m_entityManager ; 

} ; 

The map class instance is kept around in the game state class: 

class State_Game : public BaseStatej 
public : 


private : 


Map* m_gameMap; 

} ; 
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zooming 

use 

squinting, not to mention initializing and loading the map: 

void State_Game : : OnCreate ( ) { 

sf::Vector2u size = m_stateMgr- >GetContext ( ) - > 
m_wind- >GetWindowSize ( ) ; 
m_view. setSize ( size . x, size . y) ; 
m_view . set Center (size. x/2, size. y/2) ; 
m_view . zoom ( 0 . 6 f ) ; 

m_stateMgr- >GetContext ( ) - >m_wind- > 

GetRenderWindow ( ) - >setView (m_view) ; 

m_gameMap = new Map (m_stateMgr- >GetContext ( ) , this); 
m_gameMap- >LoadMap ( "media/Maps/mapl .map" ) ; 

} 

Because the map is dynamically allocated, it must be deleted in the OnDestroy 
method of the game state: 

void State_Game :: OnDestroy () { 

delete m_gameMap; 
m_gameMap = nullptr; 

} 

Now onto the final piece of this puzzle - the game state update method: 

void State_Game :: Update (const sf::Time& l_time) { 

SharedContext* context = m_stateMgr- >GetContext ( ) ; 

EntityBase* player = context- >m_entityManager- >Find (" Player ") ; 
if ( Iplayer) { 

std : : cout << "Respawning player. . . " << std: : endl ; 
context - >m_entityManager- >Add (EntityType : :Player, "Player") ; 
player = context- >m_entityManager- >Find (" Player ") ; 
player- >SetPosition (m_gameMap- >GetPlayerStart ( ) ) ; 

} else { 

m_view . setCenter (player- >GetPosition ( ) ) ; 

context - >m_wind- >GetRenderWindow ( ) - >setView (m_view) ; 

} 


sf : : FloatRect viewSpace = context->m_wind->GetViewSpace(); 
if (viewSpace . lef t <= 0) { 
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m_view . setCenter (viewSpace . width / 2 , m_view . getCenter ( ) .y) ; 
context - >m_wind- >GetRenderWindow ( ) - >setView (m_view) ; 

} else if (viewSpace . left + viewSpace . width > 

(m_gameMap- >GetMapSize ( ) . x + 1) * Sheet :: Tile_Size) 

{ 

m_view . setCenter (( (m_gameMap- >GetMapSize (). x + 1) * 

Sheet :: Tile_Size) - (viewSpace . width / 2), 
m_view . getCenter ( ) .y) ; 

context - >m_wind- >GetRenderWindow ( ) - >setView (m_view) ; 

} 

m_gameMap- >Update (l_time . asSeconds ( ) ) ; 
m_stateMgr- >GetContext ( ) - > 

m_entityManager- >Update (l_time . asSeconds ( ) ) ; 

} 

First, we determine if the player is still alive in the game by searching for them by 
order. A new 

player entity is created and the starting coordinates of the map are passed to its 
SetPosition method. 

yer entity 
use the shared 

context to obtain the render window, which will be using the updated view. Now, 
can be 

w or equal to 
t its top-left 

corner at the very edge of the screen, in order to prevent scrolling infinitely to the 

ion, the view 

the very edge of 

the map's boundaries. 

Finally, the game map, along with the entity manager, is updated right here, because 
state 

is different. 
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Summary 

Congratulations on making it past the halfway point of this book! All of the code that 
was written, the design decisions, accounting for efficiency, and trial and error has 
brought you to this point. While the game we built is fairly basic, its architecture is 
me things in 

it may not be perfect, you have also followed the golden rule of getting it working 
first, before refining it, and now you have quite a few game design patterns under 
your belt to start building more complex game applications, as well as a solid 
code-base to expand and improve. 

fficially 

finished. We have solved some quite tricky problems, written thousands of lines of 
code, and broadened our understanding of the game development process beyond 
ill ahead of us. We 

may not know where it will ultimately lead us, but one thing is for sure: now is not 
a time to stop. See you in the next chapter. 
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As we move past the halfway point of this book, the bells and whistles in our games 
are going to get more and more advanced. To showcase them properly, the genre 
of our final project will be a classical 2D Role Playing Game with orthographic 
projection. With our code-base growing at a rapid rate, poor design quickly becomes 
tedious to maintain, or even unmanageable. As new features get added, we want 
expansion of code to be easy and not slow down the overall process. This is the area 
where game programming patterns shine the brightest. 

In this chapter, we will be covering: 

• The design and implementation of the entity component system 

• Inter-system communication using the observer pattern 

• Render ordering 

• Implementation of map layers 

obust! 
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Use of copyrighted resources 

Once again, before beginning this chapter, we'd like to give credit where credit's due. 
not limited to: 

[LPC] Medieval fantasy character sprites by wulax under CC-BY-SA 3.0 and GPL 3.0 
licenses: 

http : //opengameart . org/ content /lpc -medieval -fantasy- character- sprites 

Lots of free 2D tiles and sprites by Hyptosis under the CC-BY 3.0 license: 

http : //opengameart . org/ content / lot s - of -free -2d- tiles -and- sprites -by- 
hyptosis 

d here: 

• http : / / creativecommons . org/licenses/by/ 3.0/ 

• http : // creativecommons . org/ licenses /by- sa/ 3.0/ 

• http : / /www . gnu . org/licenses/gpl-3 . 0 . html 

What is a programming pattern? 

red to, 
s not to 

say that these patterns exist as some sort of libraries out there, although there are 
ea or a 

strategy. It is a well laid out plan on tackling a certain problem, the best possible 
which is 

one of the the best reasons they should be used, 
ials and even 

classes dedicated solely to understanding and implementing them. For our purposes, 
we're going to be covering four: the entity component system, event queue, observer 
and factory patterns. We'll be talking about each one separately, as they're non 
overlapping in function, even though they can be working together. 
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The entity component system 

The entity component system is a programming pattern, which allows entities to 
possess properties and functionality through the means of composition, as opposed 
to inheritance. The biggest benefits of using this pattern include stronger decoupling 
reusability of code 
omplexity to 
your code base. 

The typical implementation of this pattern consists of three parts: 

• Entities: In most cases, entities are barely anything more than identifiers, 
slapped on a collection of components 

• Components: These are the building blocks of entities, that are nothing more 
than collections of data 

• Systems: These are specialized classes that deal with a very specific task and 
are responsible for holding all of the logic in this paradigm 


entity 

age 

ch will be 
ality we'll 
be covering soon. 

In order to differentiate between different types of components and systems, we're 
going to create a new header file, ECS_Types . h, which will be used to store this 
information: 

using ComponentType = unsigned int; 

#def ine N_COMPONENT_TYPES 32 

enum class Component! 

Position = 0, SpriteSheet, State, Movable, Controller, Collidable 

} ; 


enum class Systemj 

Renderer = 0, Movement, Collision, Control, State, SheetAnimation 

} ; 


In addition to component and system enumerations, we're also aliasing an unsigned 
integer to act as the component type and defining a macro n_component_types, 
which represents the maximum number of component types we can have. 
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What is a component? 

Within the entity component system paradigm, a component is the smallest, 
sprite. From 
data 

ation about 

the feature of an entity it represents, as illustrated below: 


V 

Movable 


Controller 


Collidable«o= 



State 

Sprite sheet 


Position 


inheritance. 

Let's take a look at a base component class definition: 

class C_Base{ 
public : 

C_Base (const Components: l_type) : m_type ( l_type ) { } 
virtual ~C_Base ( ) { } 

Component GetType ( ) { return m_type ; } 

friend std : : stringstreamS operator >> ( 
std : : stringstreams l_stream, C_Base& b) 

{ 

b . Readln ( l_stream) ; 
return l_stream; 

} 


virtual void Readln (std :: stringstreams l_stream) = 0; 
protected: 

Component m_type ; 
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The constructor of our component base class will take in the type of the component 
it represents. One thing to note is the overloaded >> operator, which calls a purely 
virtual function Readin. This serves as a quick way to read component data in from 
a file. Because each component is unique, it defines its own version of the Readin 
method in order to load its data correctly. 

The position component 

A good example of putting the base component class to work is actually 
implementing the first and arguably most common type of component: position. 

class C_Position : public C_Base{ 
public : 

C_Position() : C_Base (Component : : Position) , m_elevation ( 0 ) {} 
~C_Position ( ) { } 

void Readin ( std :: stringstream& l_stream) { 

l_stream >> m position.x >> m_position.y >> m_elevation; 

} 


const sf : : Vector2f & GetPosition ( ) { return m_position; } 
const sf : : Vector2f & GetOldPosition ( ) { return m_position01d; } 
unsigned int GetElevation ( ) { return m_elevation; } 

void SetPosition ( float l_x, float l_y) { 
m_position01d = m_position; 
m_position = sf : : Vector2f (l_x, l_y) ; 

} 


void SetPosition (const sf : : Vector2f & l_vec) { 
m_position01d = m_position; 
m_position = l_vec; 

} 

void SetElevation (unsigned int l_elevation) { 
melevation = l_elevation; 

} 

void MoveBy(float l_x, float l_y) { 
m positionOld = m position; 
m_position += sf : :Vector2f (l_x, l_y) ; 

} 
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void MoveBy(const sf : : Vector2f & l_vec) { 
m_position01d = m_position; 
m position += l_vec; 

} 


private : 

sf::Vector2f m_position; 
sf::Vector2f m_position01d; 
unsigned int m_elevation; 

} ; 


The constructor of our component base class is invoked in the initializer list, with 
the component type being passed in as the only argument. Although there are better 
ways of assigning individual component types their own unique identifiers, it's 
better to start simple for clarity's sake. 

, the position 
ity, which is 

simply a value that represents how high the entity is in relation to the map. 

it offers a 
king its 
thods reduces 

code redundancy and offers a familiar interface. 

Lastly, note the implementation of the Readln method. It uses a stringstream object 
as an argument and loads the relevant pieces of data from it. 

The bitmask 

Having a lightweight, easy-to-use as well as easy-to-expend data structure, 
representing the makeup of any given entity, as well as a set of requirements imposed 
by a system saves a lot of headaches. For us, that data structure is a bitmask. 

The standard template library provides its own version of a bitmask: 
the std : : bitset. For educational purposes, we're going to be 
implementing our own version of this class. 

As you probably know already, in binary, any and all numbers can be represented as 
a combination of zeroes and ones. However, who's to say that those two values have 
magic, any 

simple integer can be turned into a string of continuous flags that represent different 
aspects of an entity, such as which components it has, or types of components it 
needs to have in order to belong to a system. 
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Consider the following illustration: 



The only real difference in practice would be a lot more than eight flags available. 
Let's get coding: 

#include <stdint.h> 

using Bitset = uint32_t; 
class Bitmask{ 
public : 

BitmaskO : bits(0){} 

Bitmask (const Bitsets l_bits) : bits ( l_bits ) { } 

Bitset GetMaskO const{ return bits; } 

void SetMask (const Bitsets l_value) { bits = l_value; } 

bool Matches (const Bitmasks l_bits, 
const Bitsets l_relevant = 0) const 

{ 

return ( l_relevant ? 

( (l_bits . GetMask ( ) & l_relevant) == (bits & Irrelevant)) 

: (l_bits . GetMask ( ) == bits)); 

} 

bool GetBit (const unsigned int& l_pos) const { 
return ((bits&(l << l_pos) ) != 0) ; 

} 

void TurnOnBit (const unsigned int& l_pos) { 
bits |= 1 << l_pos ; 

} 

void TurnOnBits (const BitsetS l_bits) { 
bits |= l_bits ; 
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} 

void ClearBit ( const unsigned int& l_pos) { 
bits &= ~(1 << 1 pos) ; 

} 

void ToggleBit (const unsigned int& l_pos) { 
bits A = 1 << l_pos ; 

} 


void Clear (){ bits 
private : 

Bitset bits; 

} ; 


0 ; } 


We begin by defining the data type for our bitset, kindly provided by the stdint . h 
header. As the name implies, the uint32_t type is exactly 32 bits wide. Using this 
type, and not, let's say, a typical integer, eliminates the possibility of cross-platform 
differences. A regular integer could take up less or more memory, depending on the 
platform our code is executed on. Using specialized types from the stdint . h header 
ensures the exact same results, regardless of platform differences. 

The majority of the Bitmask class consists of nothing but bitwise operations, which 
ar with 

them, it's not the end of the world, however, it would be more beneficial to at least 
understand how they work before moving forward. 

Managing entities 

Now that we have the building blocks of entities defined, it's time to talk about 
this point is 

a single identifier. Knowing that, we can begin shaping the way this data is going to 
be stored, beginning, as always, with the definition of data types to be used: 

using Entityld = unsigned int ; 

using ComponentContainer = std : : vector<C_Base* > ; 
using EntityData = std : :pair<Bitmask, ComponentContainer> ; 
using EntityContainer = std : : unordered_map<EntityId, EntityData> ; 
using ComponentFactory = std : : unordered_map< 

Component , std : : function<C_Base* (void) >>; 
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The first data type we'll be working with is the entity identifier, once again represented 
by an unsigned integer. Next, a container is needed to hold all of the components for 
an entity. A vector works just fine for this purpose. Following that, we define a pair, a 
bitmask and the component container, which will hold all of the information about the 
entity. The bitmask is used here in order to alleviate the need to iterate over containers 
searching for components, when it can be quickly queried for the same purpose. The 
last piece of the entity puzzle is mapping an entity identifier to all of its data, for which 
we'll be using the unordered_map. 

ssible, we'll be 
four lines 

of type definitions here make that possible. 

Having all of the data types defined allows us to finally take a look at the entity 
manager class declaration: 

class SystemManager; 
class EntityManager { 
public : 

EntityManager (SystemManager* l_sysMgr, 

TextureManager* l_textureMgr) ; 

-EntityManager ( ) ; 

int AddEntity (const Bitmasks l_mask) ; 

int AddEntity (const std : : strings l_entityFile) ; 

bool RemoveEntity (const Entitylds l_id) ; 

bool AddComponent (const Entitylds l_entity, 
const Components; l_component) ; 

template<class T> 

T* GetComponent ( const Entitylds l_entity, 
const Components l_component) { ... } 

bool RemoveComponent (const Entitylds l_entity, 
const Components l_component) ; 
bool HasComponent (const Entitylds l_entity, 
const Components l_component) ; 

void Purge ( ) ; 
private : 

template<class T> 

void AddComponentType ( const Components l_id) { 

m_cFactory [ 1 id] = [] ()->C_Base* { return new T(); }; 

} 
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/ / Data members 
unsigned int m_idCounter; 
EntityContainer m_entities; 
ComponentFactory m_cFactory; 

SystemManager* m_systems; 
TextureManager* m_t extureManager ; 

} ; 


xist in any 

other class that serves as a container. Two different versions of adding entities 
ther for 

loading an entity configuration from a file. The method for obtaining a component 
from a specific entity is templated, reducing the amount of code that has to be 
hat is desired. 

Let's take a look at how it's implemented: 

template<class T> 

T* GetComponent (const Entitylds l_entity, 
const Components; l_component) 

{ 

auto itr = m_entities . f ind (l_entity) ; 

if (itr == m_entities . end ( ) ) { return nullptr; } 

// Found the entity. 

if (! itr- >second . first . GetBit ( (unsigned int ) l_component ) ) 

{ 

return nullptr; 

} 

// Component exists. 

autos container = itr->second. second; 

auto component = std find_if ( container . begin (), container . end () , 
[Sl_component] (C_Base* c) { 

return c->GetType() == l_component; 

}>; 

return (component != container . end ( ) ? 
dynamic_cast<T* > ( ‘component ) : nullptr); 

} 

The entity argument passed into the method is evaluated first, in order to determine 
if one with the provided identifier exists. If it does, the bitmask of that entity 
it. The 
cast 

type of the template. 
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Implementing the entity manager 

With the class definition out of the way, we can start implementing its methods. 

As per usual, let's address the constructor and destructor of the entity manager 
class first: 

EntityManager : : EntityManager (SystemManager* l_sysMgr, 

TextureManager* l_textureMgr) : m_idCounter ( 0 ) , 
m_systems ( l_sysMgr) , m_textureManager ( l_textureMgr ) 

{ 

AddComponentType<C_Position> (Component: : Position) ; 
AddComponentType<C_SpriteSheet> (Component : : SpriteSheet) ; 
AddComponentType<C_State> (Component : : State) ; 
AddComponentType<C_Movable> (Component : :Movable) ; 
AddComponentType<C_Controller> (Component: : Controller) ; 
AddComponentType<C_Collidable> (Component: :Collidable) ; 

} 

EntityManager :: -EntityManager () { Purge () ; } 

The constructor takes in a pointer to the SystemManager class, which we will be 

implementing shortly, as well as a pointer the TextureManager. In its initializer list, 

the idCounter data member is set to zero. This is simply a variable that will be used 

to keep track of the last identifier that was given to an entity. Additionally, both the 

erence. The 

components to 

the component factory. 

The destructor simply invokes a Purge method, which will be used to clean up all of 
the dynamically allocated memory and clear all possible containers in this class. 

int EntityManager : :AddEntity (const Bitmask& l_mask) { 
unsigned int entity = m_idCounter; 
if ( !m_entities . emplace (entity, 

EntityData ( 0 , ComponentContainer ( ) ) ) . second) 

{ return -1; } 

++m_idCounter ; 

for (unsigned int i = 0; i < N_COMPONENT_TYPES ; ++i){ 

if ( l_mask . GetBit ( i) ) { AddComponent (entity, (Component) i) ; } 

} 

// Notifying the system manager of a modified entity. 
m_sys terns - >EntityModif ied (entity, l_mask) ; 

m_systems - >AddEvent (entity , (EventID) EntityEvent : :Spawned) ; 
return entity; 

} 


[ 217 ] 



The More You Know - Common Game Programming Patterns 


ity pair 

is inserted into the entity container first. If the insertion was successful, a for loop 
hat type. The 

AddComponent method is then invoked, if the bitmask has the said type enabled. 

After the component insertion, the system manager is notified of an entity being 
modified, or, in this case, inserted. The entity identifier, along with the bitmask of 
the said entity is passed into the EntityModif ied method of the system manager, 
ned. 

The identifier of the newly created entity is then returned. If the method failed to add 
an entity, -1 is returned instead, to signify an error. 

Removing an entity is every bit as easy, if not more so: 

bool EntityManager :: RemoveEntity (const Entitylds l_id) { 
auto itr = identities . f ind (l_id) ; 
if (itr == identities . end ( ) ) { return false; } 

// Removing all components. 

while ( itr- >second . second . begin ( ) != itr- >second . second . end ()) { 

delete itr- >second . second . back ( ) ; 
itr- >second. second. pop_back () ; 

} 

identities . erase ( itr) ; 
m_systems - >RemoveEntity (l_id) ; 
return true; 

} 

namically 

allocated memory of every single component it has is first freed, and the component 
he entity 

container and the system manager is notified of its removal. 

bool EntityManager :: AddComponent (const Entitylds l_entity, 
const Components; l_component) 

{ 

auto itr = m entities . find (l_entity) ; 

if (itr == identities . end ( ) ) { return false; } 

if ( itr- >second . first . GetBit ( (unsigned int) l_component) ) 

{ 

return false; 

} 

// Component doesn't exist. 

auto itr2 = m_cFactory . f ind (l_component) ; 

if (itr2 == m_cFactory . end ( ) ) { return false; } 

// Component type does exist. 
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C_Base* component = itr2 - >second ( ) ; 

itr- >second . second . emplace_back (component ) ; 

itr- >second . first . TurnOnBit ( (unsigned int ) l_component ) ; 

// Notifying the system manager of a modified entity. 
m_sys terns- >EntityModif ied ( l_entity , itr- > second .first) ; 
return true ; 

} 

Adding a component to an entity begins by verifying an entity with the provided 
identifipe added 

to the entity, the lambda-function container is queried for the desired type. Once 
t vector. 

The bitmask is then modified to reflect the changes made to the entity. The system 
manager is notified of those changes as well. 

ent from 
an entity: 

bool EntityManager :: RemoveComponent (const Entityld& l_entity, 
const Components l_component) 

{ 

auto itr = m_entities . f ind (l_entity) ; 
if (itr == m_entities . end ( ) ) { return false; } 

// Found the entity. 

if (! itr- >second . first . GetBit ( (unsigned int ) l_component ) ) 

{ 

return false; 

} 

// Component exists. 

autos container = itr->second. second; 

auto component = std find_if ( container . begin (), container . end () , 
[Sl_component] (C_Base* c) { 

return c->GetType() == l_component; 

}>; 

if (component == container . end ()) { return false; } 
delete (*component); 
container. erase (component) ; 

itr->second. first . ClearBit ( (unsigned int) l_component) ; 

m_systems - >EntityModif ied (l_entity , itr->second. first) ; 
return true; 

} 
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After confirming that both the entity and component exist, the memory allocated 
for the component is freed and the component itself is erased. The bitmask also gets 
modified to reflect these changes. Much like before, the system manager needs to 
know if an entity was altered, so the EntityModif ied method is invoked. 

A fairly useful method to have for outside classes is one that checks if an entity 
has a certain type of component: 

bool EntityManager :: HasComponent (const Entityldk l_entity, 
const Components; l_component) 

{ 

auto itr = m entities . find (l_entity) ; 

if (itr == identities . end ( ) ) { return false; } 

return itr- >second . first . GetBit ( (unsigned int ) l_component ) ; 

} 

first, then 

checking its bitmask for a certain component type. 

t up to the 
Purge method: 

void EntityManager :: Purge () { 
m_systems->PurgeEntities ( ) ; 
for(autoS entity : m_entities) { 

for (auto ^component : entity . second . second) { delete component;} 
entity . second. second . clear ( ) ; 
entity . second . first . Clear ( ) ; 

} 

m_entities . clear ( ) ; 
m_idCounter = 0; 

} 

The system manager is notified to remove all of its entities first. While iterating over 
omponent. The 
is cleared and 

the identification counter is set back to 0. 

The factory pattern 

r will not 

be setting up and initializing every single component by hand. Setting up entities 
ode as 
ts to solve 

this particular problem. It is simply referred to as the factory pattern. 
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s a class with 
ome vague 
on it was 

given, a class or a number of classes and returns a handle to them, effectively cutting 
and. In other 
the name 

"factory". This functionality was already achieved in a way by creating entities based 
. Having 

a more pristine way of actually setting up these entities requires a more elaborate 
blueprint, so why not use text files? For example: 


Name Player 
Attributes 63 

| Component | ID | Individual attributes | 
Component 0001 


plain text as a 

blueprint and loaded at any time to produce any number of entities with exactly the 
same qualities. Let's take a look at how processing entity files could be achieved: 

int EntityManager : :AddEntity (const std :: strings l_entityFile) { 
int Entityld = -1; 

std: : if stream file; 

file . open (Utils : : GetWorkingDirectory ( ) + 

"media/Entities/ " + l_entityFile + ".entity"); 
if ( ! f ile . is_open ( ) ) { 

std::cout << "! Failed to load entity: " 

<< l_entityFile << std:: endu- 
re turn -1; 

} 

std::string line; 
while ( std : : get line ( f ile , line) ) { 
if (line[0] == 1 | 1 ) { continue; } 
std: : stringstream keystream ( line) ; 
std:: string type; 
keystream >> type; 
if (type == "Name") { 

} else if (type == "Attributes")! 
if (Entityld != -1) { continue; } 

Bitset set = 0; 

Bitmask mask; 
keystream >> set; 
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mask . SetMask (set) ; 

Entityld = AddEntity (mask) ; 
if (Entityld == -1) { return -1; } 

} else if (type == "Component")! 
if (Entityld == -1) { continue; } 
unsigned int c_id = 0; 
keystream >> c_id; 

C_Base* component = GetComponent<C_Base> 

(Entityld, (Component) c_id) ; 
if (! component) { continue; } 
keystream >> ‘component; 

if (component- >GetType ( ) == Component SpriteSheet ) { 
C_SpriteSheet* sheet = (C_SpriteSheet* ) component ; 
sheet - >Create (m_textureManager ) ; 

} 

} 

} 

file . close ( ) ; 
return Entityld; 

} 

Loading entity files isn't much different from any other files we've processed in the 
past. For now, reading entity names hasn't yet been implemented. The attributes 
omponents 

of AddEntity, 


must 

make sure that the entity has been created. This means that the "Attributes" line 
has to come before the individual component data in the entity file. If the entity ID 
ining the 

actual object based on it. The overloaded > > operator comes in handy here, since it 
greatly simplifies actually streaming in the component data. 

o be checked 
lass, if it needs 
the sprite 

sheet component that will represent some entities. 
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Designing the systems 

mg 

component remains to be the system. As the name loosely implies, systems are 

tween 

ks are all 

etween 

ut in an 

ideal world. In reality, as hard as one tries to decouple and categorize logic or data, 
some things still remain loosely connected, which is just the nature of the beast, 
ctionality 

also needs to be invoked as a consequence of a totally unrelated system's actions. To 
put it simply, there needs to be a way for systems to talk to each other without them 
knowing anything about how the other one works. 

Entity events 

nter-system 
or those 
ng else, 
ible list of 
entity events: 

enum class EntityEvent{ 

Spawned, Despawned, Colliding_X, Colliding_Y, 

Moving_Left, Moving_Right , Moving_Up, Moving_Down, 

Elevation_Change , Became_Idle, Began_Moving 

} ; 


This should give you a pretty good idea of how system communication will take 
place. Let's say that an entity is moving in the left direction. The "movement system" 
starts dispatching events, saying that it's in motion. The "animation system" listens 
for those events, and when they're received, it proceeds to increase frames in the 
entity's sprite sheet. Keep in mind that all of these chunks of logic are still completely 
separate from one another. The "movement system" is not increasing the frames of the 
entity's sprite sheet. It's simply saying to all of the other systems "Hello, I am moving 
entity x to the left," while they listen and react. It sounds like we can benefit from the 
"event queue." 
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Entity event queue 

The event queue is a programming pattern, which is used to decouple when an 
event is fired from when it's actually processed. This illustration should capture 
the essence of it: 


SystemManager : : AddEvent 

1 


CollidingX 


MovingLeft 

Began_Moving 






— Systei 

mManager: :HandleE 

vents-J 


e data that 

is pushed onto it earliest is removed first. This serves our needs nicely. As the 
definition of the event queue states, its events are processed at a completely different 
time in relation to them being added. With that in mind, let's start designing the 
EventQueue class: 

using EventID = unsigned int; 

class EventQueue { 
public : 

void AddEvent (const EventID& l_event) {m_queue .push (l_event) ; } 

bool ProcessEvents (EventID& l_id) { 

if (m_queue . empty ()) { return false; } 
l_id = m_queue . f ront ( ) ; 
m_queue . pop ( ) ; 
return true; 

} 


void Clear (){ while (! m_queue . empty ()) { m_queue . pop ( ) ; }} 
private : 

std : : queue<EventID> m_queue; 

} ; 
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The event identifier is represented with an unsigned integer. In order to store the 
actual events, we'll be using, appropriately enough, a queue container. Adding an 
event to it is as simple as any other STL container. This class offers a method that 
eturns a 
nd its 
method 

is called. This is similar to the way SFML handles events. 

The base system 

In order to begin implementing our systems, they must first have a common base 
class, which not only provides a common interface that must be implemented, but 
also eliminates code redundancy. Much like most other classes we build, it will have 
its own data types defined: 

using EntityList = std : : vector<EntityId> ; 
using Requirements = std : : vector<Bitmask> ; 

The system identifier, just like the component identifier, is represented by an 
unsigned integer. All of the entity identifiers will be stored in a vector container, 
much like the requirement bitmasks. The reason we would ever want to have more 
than one requirement bitmask is to have the ability to define combinations of different 
types of components that could still belong to the same system. A good example of 
that would be different drawable types belonging to the same rendering system. 

Let's take a look at the header of our system base class: 

class SystemManager; 
class S_Base{ 
public : 

S_Base (const System& l_id, SystemManager* l_systemMgr) ; 
virtual ~S_Base(); 

bool AddEntity (const Entityldk l_entity) ; 
bool HasEntity (const Entityldk l_entity) ; 
bool RemoveEntity (const Entityld& l_entity) ; 

System Getld ( ) ; 

bool FitsRequirements (const Bitmaskk l_bits) ; 
void Purge ( ) ; 

virtual void Update (float l_dT) = 0; 
virtual void HandleEvent (const Entityldk l_entity, 
const EntityEventk l_event) = 0; 
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protected: 

System m_id; 

Requirements m_requiredComponents ; 
EntityList m_entities; 

SystemManager* m_systemManager ; 

} ; 


s own 

version of event handling. Additionally, systems having access to their own manager 
is also desired. Everything else that is not system-specific, like checking requirement 
bitmasks, is handled by the base class. 

Implementing the base system 

Because all systems require a pointer to the system manager, there's an issue of cross- 
the inclusion 

of the system manager header in the implementation file takes care of the issue: 

#include " System_Manager . h" 
tructor 

and destructor: 

S_Base :: S_Base (const Systems l_id, SystemManager* l_systemMgr) 

: m_id(l_id), m_systemManager ( l_systemMgr ) { } 

S_Base : : ~S_Base ( ) { Purge () ; } 

Each system has to have its own identifier, much like all of the components. That 
gets passed in the argument list to the constructor, along with a pointer to the system 
in an 

initializer list, the constructor of a base system does nothing else. 

The destructor, following the typical fashion, invokes the Purge method to do the 
cleanup. 

bool S_Base : :AddEntity (const Entityldk l_entity) { 
if (HasEntity (l_entity) ) { return false; } 
m_entities . emplace_back (l_entity) ; 
return true; 

} 
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Adding an entity to a system is fairly easy. If the identifier that was provided as an 
shed into the 
ntifier? Let's 
find out: 

bool S_Base :: HasEntity (const Entityldk l_entity) { 
return std: : find (m_entities . begin ( ) , 

m_entities . end ( ) , l_entity) != m_entities . end ( ) ; 

} 

Utilizing the std : : find function allows us to sum up this method in a single line. 
Removing an entity also takes advantage of a similar function: 

bool S_Base :: RemoveEntity (const Entityld& l_entity) { 

auto entity = std :: find_if (m_entities . begin () , m_entities . end ( ) , 
[&l_entity] (Entityld& id) { return id = l_entity; }); 
if (entity == m_entities . end ( ) ) { return false; } 
m_entities . erase (entity) ; 
return true; 

} 

In this case, we're using the std : : f ind_if function, which takes a predicate as the 
lements 

together in order to find a match. In this case, we simply construct a lambda function 
that takes in an Entityld and returns a Boolean value, which will tell the find 
d. 

nts in order 

to be added to it. That's where this method comes in: 

bool S_Base :: FitsRequirements (const Bitmask& l_bits) { 
return std: :find_if (m_requiredComponents . begin ( ) , 
m_requiredComponents . end ( ) , [&l_bits] (Bitmaskk b) { 
return b . Matches ( l_bits , b . GetMask ( ) ) ; 

}) != mrequiredComponents . end ( ) ; 

} 

It takes in a bitmask as an argument and utilizes the same std : : f ind if function 
en need to 
defito have 

this functionality when the need for it arises. 

Lastly, here's the method for cleaning up: 

void S_Base :: Purge () { m_entities . clear () ; } 

Because there's no actual dynamic memory being allocated here, it's safe to just 
empty the container of all the entity identifiers. 


[ 227 ] 



The More You Know - Common Game Programming Patterns 


Handling messages 

Entity events, while useful for a lot of situations, aren't perfect for everything. For 

eue. The 

teful. 

Instead, why not have an additional method of communication that not only carries 
data around, but also allows systems to pick and choose what they want to receive? 
just so 

happens to be yet another programming pattern, which allows easy implementation 
of the message-subscription approach. 

The observer pattern 

As the name entails, the observer pattern allows its users to pick and choose 
what they will be notified of. In other words, the observer will lay dormant after 
notified if 
ation of 

the Observer base class: 

class Observer! 
public : 

virtual -Observer ( ) { } 

virtual void Notify (const Messages; l_message) = 0; 

} ; 


The Observer class is simply an interface, the inheritors of which must define a 
s we desire 

in our game wouldn't be possible without it. Let's take a look at what these observers 
will be notified with: 

using MessageType = unsigned int; 

struct TwoFloats{ float m_x; float m_y; }; 

struct Message! 

Message (const MessageTypeS l_type) : m_type ( l_type ) { } 

MessageType m_type; 
int m_sender; 
int m_receiver; 

union{ 

TwoFloats m_2f; 
bool m_bool ; 
int m_int ; 

} ; 

} ; 
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s, as well as 

the message type, it employs a union in order to avoid inheritance. That essentially 
same space 

in memory, and only one of them can be valid at a time. 

The last piece of the puzzle is containing all possible observers in a Communicator 
class. For this, we'll be using a vector: 

using ObserverContainer = std : : vector<Observer* > ; 

Because this class has relatively simple methods that simply deal with managing a 
vector container, let's take a look at the full class definition head to toe: 

class Communicator { 

public : 

-Communicator () { m_observers . clear () ; } 

bool AddObserver (Observer* l_observer) { 

if (HasObserver (l_observer) ) { return false; } 
m_observers . emplace_back (l_observer) ; 
return true; 

} 

bool RemoveObserver (Observer* l_observer) { 

auto observer = std: : find_if (m_observers .begin () , 
m_observers . end ( ) , [&l_observer] (Observer* o) { 
return o == l_observer; }) ; 
if (observer == m_observers . end ( ) ) { return false; } 
m_observers . erase (observer) ; 
return true; 

} 

bool HasObserver (const Observer* l_observer) { 

return (std: : find_if (m_observers .begin () , m_observers . end ( ) , 
[&l_observer] (Observer* o) { 
return o == l_observer; 

}) != m_observers . end ( ) ) ; 

} 

void Broadcast (const Messages l_msg) { 

for(auto& itr : m_observers) { itr- >Notify ( l_msg) ; } 

} 

private : 

ObserverContainer m_observers; 

} ; 
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The basic methods for adding, removing and looking for an observer are all typical. 
One thing to note, however, is the Broadcast method, which simply invokes the 
Notify method of an observer and passes in a message to send. 

Last, and defi 
observer approach to use: 

class S_Base : public Observer! ... } 

Because the base system class has virtual methods, it doesn't need to implement 
its own version of Notify. That will be the job for all the systems that inherit from 
this class. 

The message handler class 

ke a look at 
ion: 


using Subscribtions = std: : unordered_map< 

EntityMessage , Communicator ; 

Each possible message type will have its own communicator that will broadcast the 
message to all of its observers. Using an unordered_map is perfect for expressing 
such a relationship. 

The message handler is a very simple class, so let's take a look at its entire 
implementation: 

class MessageHandler { 
public : 

bool Subscribe (const EntityMessage& l_type 
Observer* l_observer) 

{ 

return m_communicators [l_type] . AddObserver (l_observer) ; 

} 

bool Unsubscribe (const EntityMessage& l_type, 

Observer* l_observer) 

{ 

return m_communicators [l_type] . RemoveObserver ( l_observer ) ; 

} 

void Dispatch (const Messaged l_msg) { 
auto itr = m_communicators . f ind ( 

(EntityMessage) l_msg.m_type) ; 
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if (itr == m_communicators . end ( ) ) { return; } 
itr- >second. Broadcast (l_msg) ; 

} 

private : 

Subscriptions m_communicators ; 

} ; 


ating the 

unordered map data container. When a message is dispatched, the message type in 
S Broadcast 

method is invoked with the message passed in as the argument. 

At this point you might be wondering what kind of messages we'll be handling. Let's 
take a gander at the EntityMes sages . h file: 

enum class EntityMessage { 

Move, Is_Moving, State_Changed, Direction_Changed, 

Switch_State , Attack_Action, Dead 

} ; 


reading 
ding to 

contain extra data or only ever applying to a single system. 

Managing systems 

Finally, we've arrived at the last stop on the entity component system route: 
handling systems themselves. Let's quickly review our custom data types for 
this class: 

using SystemContainer = std : : unordered_map< System, S_Base* > ; 
using EntityEventContainer = std : : unordered_map< 

Entityld, EventQueue> ; 

The first data type, SystemContainer, is really hard to misinterpret. An unordered 
map is used to link system identifiers to actual systems. The second type definition 
red map and 

links entity identifiers to EventQueue instances, that all hold events for a specific 
entity until they're processed. 

It's time to design the system manager class: 

class EntityManager ; 
class SystemManager { 
public : 

SystemManager ( ) ; 
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-SystemManager ( ) ; 

void SetEntityManager (EntityManager* l_entityMgr) ; 

EntityManager* GetEntityManager ( ) ; 

MessageHandler* GetMessageHandler ( ) ; 

template<class T> 

T* GetSystem (const Systemk l_system) { . . . } 

void AddEvent (const Entityld& l_entity, const EventID& l_event) ; 

void Update (float l_dT) ; 
void HandleEvents ( ) ; 

void Draw (Window* l_wind, unsigned int l_elevation) ; 

void EntityModif ied (const Entityld& l_entity, 
const BitmaskSc l_bits) ; 
void RemoveEntity (const Entityld& l_entity) ; 

void PurgeEntities ( ) ; 
void PurgeSystems ( ) ; 
private : 

SystemContainer m_systems; 

EntityManager* m_entityManager ; 

EntityEventContainer m_events; 

MessageHandler m_messages; 

} ; 

As expected, it needs to have methods for adding and handling events, updating 
quests, 

and obtaining them as well. The template method for getting a particular system is 
implemented this way: 

template<class T> 

T* GetSystem (const Systems l_system) { 
auto itr = m_systems . f ind (l_system) ; 
return (itr != m__systems . end ( ) ? 

dynamic_cast<T*> ( itr- >second) : nullptr) ; 

} 

Just like the entity manager's method of obtaining components, this method relies 
in the 

correct form. 
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Implementing the system manager 

Cross-inclusion peaks its ugly head once more, so we must combat it with forward 
declarations and inclusions of headers in the implementation files: 

#include "Entity_Manager . h" 

With that out of the way, we can now start implementing the constructor and 
destructor: 

SystemManager : : SystemManager ( ) : m_entityManager (nullptr ) { 
m_systems [System: : State] = new S_State (this) ; 
m_systems [System: : Control] = new S_Control (this) ; 
m_systems [System: : Movement] = new S_Movement (this) ; 
m_systems [System: :Collision] = new S_Collision (this) ; 
m_systems [System :: SheetAnimation] = new S_SheetAnimation (this) ; 
rn_systems [System :: Renderer] = new S_Renderer (this) ; 

} 

SystemManager: : -SystemManager ( ) { 

PurgeSystems () ; 

} 

ializing all of 

the systems it holds. The destructor performs its usual job of cleaning up the mess, 
which is entrusted to the PurgeSystems method. 

and vice 

versa, the one that's instantiated first will not simply be able to take a pointer to the 
other class in its constructor, hence the need for the SetEntityManager method: 

void SystemManager: : SetEntityManager (EntityManager* l_entityMgr) { 
if ( ! m_entityManager ) { m_entityManager = l__entityMgr ; } 

} 

its data 
members: 

EntityManager* SystemManager: : GetEntityManager ( ) { 
return m_entityManager ; 

} 

MessageHandler* SystemManager: : GetMessageHandler ( ) { 
return &m_messages ; 

} 
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This ensures that all systems have access to the message handler, as well as the entity 
handler. 

ntity: 

void SystemManager : :AddEvent (const Entityldk l_entity, 
const EventID& l_event) 

{ 

m_events [l_entity] .AddEvent (l_event) ; 

} 

Using an unordered_map structure here really makes this method simple and neat. 
The entity identifier being the key, it's easy to access its individual event queue and 
add to it. 

Providing we want those systems to tick, an update loop is in order: 

void SystemManager :: Update ( float l_dT) { 
for(auto &itr : m_systems) { 
itr. second- >Update (l_dT) ; 

} 

HandleEvents () ; 

} 

Here, every single system's update method is invoked and the elapsed time is passed 
dated. Time 
to dissect that method: 

void SystemManager: : HandleEvents ( ) { 
for(auto &event : m_events) { 

Event ID id = 0; 

while (event . second . ProcessEvents (id) ) { 
for (auto ^system : m_systems) 

{ 

if (system. second- >HasEntity (event . first) ) { 

system . second- >HandleEvent (event . first , (EntityEvent) id) ; 

} 

} 

} 

} 

} 
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We begin by iterating over the event queues of different entities. An event identifier 
variable is set up and used in a while loop by reference, in order to obtain information 
from the queue. Every system in the manager is iterated over and checked for having 
the entity of interest. If it does, the system's HandleEvent method is invoked and the 
relevant information is passed in. That, in a nutshell, concludes event management on 
a larger scale. Now every individual system only has to worry about which events it 
wants to handle and how it wants to respond to them. 

ing to need 
a Draw method: 

void SystemManager :: Draw (Window* l_wind, 
unsigned int l_elevation) 

{ 

auto itr = m systems . find (System :: Renderer) ; 
if (itr == m systems . end ()) { return; } 

S_Renderer* system = (S_Renderer* ) itr- >second; 
system- >Render ( l_wind, l_elevation) ; 

} 

e than 

suffices. Ergo, the renderer system is located in the system container and type-cast 
up from the base class. Its Render method is then invoked with relevant arguments, 
this way 

allows the feel of "depth" to be achieved within our game, 
these changes 

and properly take in or dispose of them, given the circumstances. This specific 
ion 

of the entity manager class, so let's take a look at how it works: 

void SystemManager :: EntityModified (const Entityldk l_entity, 
const Bitmaskk l_bits) 

{ 

for(auto &s_itr : m_systems) { 

S_Base* system = s_itr . second; 
if ( system- >FitsRequirements (l_bits) ) { 
if ( ! system- >HasEntity (l_entity) ) { 
system- >AddEntity (l_entity) ; 

} 

} else { 

if (system->HasEntity (l_entity) ) { 
system- >RemoveEntity ( l_entity) ; 

} 

} 

} 

} 
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Upon any changes regarding entities taking place, the EntityModif ied method 
must be invoked with the identifier of the entity and its new bitmask passed in as 
arguments. Every system is then iterated over. Their respective FitsRequirements 
methods are invoked with the new bitmask as the argument. If the entity fits the 
requirements of a system and it doesn't belong to it, it is added. If, however, the entity 
does not fit these requirements but a system still has this entity, it's removed. The use 
of this simple concept allows entities to be dynamic in structure. Any given entity can 
lose or gain a component and immediately "transform" into something else. 

Removal of entities is quite simple: 

void SystemManager :: RemoveEntity (const Entityldk l_entity) { 
for (auto ^system : m_systems) { 

system. second- >RemoveEntity (l_entity) ; 

} 

} 


All that needs to happen here is the RemoveEntity method of every system being 
invoked, which is quite similar to purging all entities: 

void SystemManager: : PurgeEntities ( ) { 
for (auto ^system : m_systems) { 
system . second- >Purge ( ) ; 

} 

} 

Getting rid of all systems in the system manager is also a cake walk: 

void SystemManager: : PurgeSystems ( ) { 
for (auto &system : m_systems) { 
delete system. second; 

} 

m_systems . clear ( ) ; 

} 

Because systems are dynamically allocated, the memory has to be freed for each of 
them. The system container is then simply cleared. 

This last method marks the completion of our system manager, as well as the core 
s for shaping 

our game are now present, so let's implement the first and most important system in 
the game: the Tenderer. 
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Implementing the rendering system 

that 

at an entity 
tation. For 
a single 
color fie 

components. Let's see what we can come up with: 

class C_Drawable : public C_Base{ 
public : 

C_Drawable (const Components: l_type) : C_Base (l_type) { } 
virtual ~C_Drawable ( ) { } 

virtual void UpdatePosition ( const sf : : Vector2f& l_vec) = 0; 
virtual const sf : : Vector2u& GetSizeO = 0; 
virtual void Draw ( sf : : RenderWindow* l_wind) = 0; 
private : 


} ; 


The fiin a 

component type, and simply passes it to the base class. Since c_Drawable only has 
ed as a mold 

to shape other drawable components. It requires all derived classes to implement 
awing it 
on screen. 

The sprite sheet component 

With the base class set up, it's time to take a look at creating the sprite sheet 
component: 

class C_SpriteSheet : public C_Drawable{ 
public : 


private : 

SpriteSheet* m_spriteSheet; 
std: : string m_sheetName; 

} ; 
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This component will, of course, be utilizing the SpriteSheet class we built in the 
heet name 
on. Let's begin 

implementing the sprite sheet component: 

C_SpriteSheet ( ) : C_Drawable (Component : : SpriteSheet) , 
m_spriteSheet (nullptr) { } 

~C_SpriteSheet () { 

if (m_spriteSheet) { delete m_spriteSheet ; } 

} 

izer list to set 

up the component type and set the sprite sheet pointer to NULL, while the destructor 
eet. 

the sprite 
sheet name: 

void Readln (std : : stringstream& l_stream) { 
l_stream >> m_sheetName; 

} 

to the 

texture manager. In order to set up the sprite sheet properly, the Create method 
is introduced: 

void Create (TextureManager* l_textureMgr , 
const std : : strings l_name = "") 

{ 

if (m_spriteSheet ) { return; } 

m_spriteSheet = new SpriteSheet ( l_textureMgr) ; 
m_spriteSheet- >LoadSheet ( "media/ Spritesheets/ " + 

(l_name != "" ? l_name : m_sheetName) + ".sheet"); 

} 

As seen previously, this particular method is used to set up the sprite sheet component 
during entity loading. It first checks if the memory for the m spriteSheet data 
member hasn't already been allocated. If it hasn't, a new SpriteSheet object is created 
with the texture manager pointer passed in as its sole argument. The rest of the code 
deals with the second, optional argument. The name of the texture can be passed to the 
Create method itself, or it can use the m_sheetName data member that has been read 
in from the entity file. 
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Lastly, all of the virtual methods of the c_Drawable class must be implemented here: 

SpriteSheet* GetSpriteSheet ( ) { return m_spriteSheet ; } 
void UpdatePosition (const sf : : Vector2f & l_vec) { 
m_spriteSheet->SetSpritePosition (l_vec) ; 

} 

const sf : : Vector2u& GetSize(){ 

return m_spriteSheet- >GetSpriteSize ( ) ; 

} 

void Draw ( sf : : RenderWindow* l_wind) { 
if ( !m_spriteSheet) { return; } 
m_spriteSheet->Draw (l_wind) ; 

} 

All of the work done on the SpriteSheet class in the past makes this pretty easy. 
One thing to note is that due to the nature of loading sprite sheet components, it 
may be wise to check if it has actually been allocated, before attempting to draw it. 

The Tenderer 

With the simple part out of the way, let's focus on creating our first system ever built, 
the Tenderer: 

class S_Renderer : public S_Base{ 
public : 

S_Renderer (SystemManager* l_systemMgr ) ; 

~S_Renderer ( ) ; 

void Update (float l_dT) ; 

void HandleEvent (const Entitylds l_entity, 
const EntityEventS l_event) ; 
void Notify(const Messages l_message) ; 
void Render (Window* l_wind, unsigned int l_layer) ; 
private : 

void SetSheetDirection (const Entitylds l_entity, 
const Directions; l_dir) ; 
void SortDrawables ( ) ; 

} ; 
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e, with the 

exception of private methods, specific to the function that each individual system 
performs. Each system must implement its own Update and HandleEvent methods. 

Notify 


S_Renderer: : S_Renderer (SystemManager* l_systemMgr) 

: S_Base (System: :Renderer, l_systemMgr) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : Position) ; 
req . TurnOnBit ( (unsigned int ) Component : : SpriteSheet) ; 
m_requiredComponents .push_back (req) ; 
req . Clear ( ) ; 

m_systemManager- >GetMessageHandler ( ) - > 

Subscribe (EntityMessage : : Direction_Changed, this ) ; 

} . 

S_Renderer : : ~S_Renderer ( ) { } 

ate type, 

along with a pointer to the system manager, the Tenderer sets up a bitmask of 
requirements an entity has to meet in order to belong to this system. As you can see, 
it only needs to have the position and sprite sheet components. Once the requirement 
bitmask is added to the system, it also subscribes to the Direction_Changed 
message type. This utilizes the observer pattern discussed previously. 

Let's take a look at the update method: 

void S_Renderer :: Update ( float l_dT) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for (auto kentity : m_entities) 

{ 

C_Position* position = entities-> 

GetComponent<C_Position> (entity, Component: : Position) ; 
C_Drawable* drawable = nullptr; 

if (entities- >HasComponent (entity, Component :: SpriteSheet )) { 
drawable = entities -> 

GetComponent<C_Drawable> (entity , Component: : SpriteSheet ) ; 

} else { continue; } 

drawable- >UpdatePosition (position- >GetPosition ( ) ) ; 

} 

} 
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During iteration over all of the entities that belong to this system, the position and 
e's 

position is then updated through the use of its UpdatePosition method. This 
in 

the future. 

Next, let's handle the appropriate events: 

void S_Renderer :: HandleEvent (const Entityldk l_entity, 
const EntityEventk l_event) 

{ 

if (l_event == EntityEvent : : Moving_Lef t | 
l_event == EntityEvent : : Moving_Right | | 
l_event == EntityEvent : :Moving_Up | 
l_event == EntityEvent : :Moving_Down | 
l_event == EntityEvent :: Elevation_Change | j 
l_event == EntityEvent :: Spawned) 

{ 

SortDrawables () ; 

} 

} 

position or 
to assure the 

correct layering. The result of this is quite worth the trouble: 



The code for message handling here is as follows: 

void S_Renderer :: Notify ( const Messaged l_message) { 
if (HasEntity ( l_message . m_receiver ) ) { 

EntityMessage m = (EntityMessage) l_message .m_type; 
switch (m) { 

case EntityMessage: : Direction_Changed : 
SetSheetDirection ( l_message . m_receiver , 
(Direction) l_message . m_int) ; 
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break ; 

} 

} 

} 

at entities 

they have, and the Tenderer only deals with a single message type that pertains 
to specifiists 
s the 
just it. 

Now, let's address the main purpose the Tenderer system exists: 

void S_Renderer :: Render (Window* l_wind, unsigned int l_layer) 

{ 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for (auto kentity : m_entities) { 

C_Position* position = entities-> 

GetComponent<C_Position> (entity, Component: : Position) ; 
if (position- >GetElevation ( ) < l_layer) { continue; } 
if (position- >GetElevation ( ) > l_layer) { break; } 

C_Drawable* drawable = nullptr; 
if ( ! entities - >HasComponent (entity. 

Component: : SpriteSheet) ) 

{ 

continue ; 

} 

drawable = entities-> 

GetComponent<C_Drawable> (entity, Component: : SpriteSheet ) ; 
sf : : FloatRect drawableBounds; 

drawableBounds . lef t = position- >GetPosition (). x - 
(drawable->GetSize ( ) .x / 2) ; 
drawableBounds . top = position- >GetPosition (). y - 
drawable- >GetSize ( ) ,y; 

drawableBounds . width = drawable- >GetSize ( ) .x; 
drawableBounds . height = drawable- >GetSize (). y; 
if ( ! l_wind- >GetViewSpace ( ) . intersects ( 
drawableBounds) ) 

{ 

continue ; 

} 

drawable- >Draw ( l_wind- >GetRenderWindow ( ) ) ; 

} 

} 
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rence here 
that has 

many different layers entities can be, for the lack of better term, "sandwiched" in, 
orrect draw 

order and offer the feeling of depth, as illustrated here: 



The second half of the Render method is devoted to entity culling. First, a rectangle 
In the case 

of a sprite sheet, we know that its origin is set at the point of half its width and its 
full height. Using this information, the rectangle structure is properly set up and 
the sprite 

is on screen and should be drawn. 

Re-using code as much as possible makes life easier in the long run, hence 
g 

modifications of entity components. For example: 

void S_Renderer :: SetSheetDirection (const Entityldk l_entity, 
const Directions^ l_dir) 

{ 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
if ( ! entities->HasComponent (l_entity. 

Component: : SpriteSheet) ) 

{ 

return; 

} 

C_SpriteSheet* sheet = entities-> 

GetComponent<C_SpriteSheet> (l_entity, Component : : SpriteSheet) ; 
sheet - >GetSpriteSheet ( ) - >SetDirection ( l_dir ) ; 

} 

The SetSheetDirection method simply fetches the sprite sheet component and 
changes its direction. 
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drawables 
res them 

being sorted. This is where the SortDrawables method comes in: 

void S_Renderer: : SortDrawables ( ) { 

EntityManager* e_mgr = m_systemManager- >GetEntityManager ( ) ; 
std : : sort (m_entities .begin ( ) , m_entities . end ( ) , 

[e_mgr] (unsigned int 1_1, unsigned int 1_2) 

{ 

auto posl = e_mgr-> 

GetComponent<C_Position> ( 1_1 , Component: :Position) ; 
auto pos2 = e_mgr-> 

GetComponent<C_Position> ( 1_2 , Component: :Position) ; 
if (posl- >GetElevation ( ) == pos2 - >GetElevation ( ) ) { 

return posl - >GetPosition ( ) . y < pos2 - >GetPosition ( ) . y ; 

} 

return posl - >GetElevation ( ) < pos2 - >GetElevation ( ) ; 

}>; 

} 

Here, we simply invoke the std : : sort function, with the last argument being the 
priority 

when entity sprites are being sorted. Anything with a higher elevation will be drawn 
on top, while sprites on the same elevation are sorted based on their Y coordinate. 

With that, the rendering system is now complete! Putting all of the pieces together is 
the final step in employing the entity component system pattern in our game. 

Putting the ECS to work 

ication, we 
he majority 
the best way 
to do so: 

struct SharedContext { 

SharedContext () : 

m_systemManager (nullptr ) , 
m_entityManager (nullptr ) , 

•••{}’ 


SystemManager* m_systemManager ; 
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EntityManager* m_entityManager ; 


ck of 

in Game . h: 

class Game{ 

private : 


SystemManager m_systemManager ; 
EntityManager m_entityManager ; 


} ; 


These classes have to be properly initialized, which is done in Game . cpp: 

Game :: Game () : m_window ( "Chapter 8", sf : : Vector2u (800 , 600) ) , 

m_entityManager (&m_systemManager , &m_textureManager) , 

m_stateManager ( &m_context ) 

{ 


m_systemManager . SetEntityManager (&m_entityManager) ; 
m_context .msystemManager = &m_systeinManager ; 
m_context .m_entityManager = imentityManager ; 


Notice that the entity manager is initialized in the initializer list. The system manager 
is then given a pointer to the entity manager, and both of these classes are added to 
the shared context. 

Next up, some changes have to be made to the game state: 

class State_Game : public BaseState{ 
public : 


void PlayerMove (EventDetails* l_details) ; 


private : 


Void UpdateCamera ( ) ; 
int m_player; 
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The game state currently keeps track of the player's entity identifier in addition to 
ayer, 

which will be set up as a callback like so: 

void State_Game : : OnCreate ( ) { 

evMgr- >AddCallback (StateType : :Game, " Player_MoveLef t " , 

&State_Game :: PlayerMove , this) ; 
evMgr- >AddCallback (StateType : :Game, " Player_MoveRight " , 

&State_Game :: PlayerMove , this); 
evMgr- >AddCallback (StateType : :Game, "Player_MoveUp" , 

&State_Game :: PlayerMove , this); 
evMgr- >AddCallback (StateType : :Game, " Player_MoveDown" , 

&State_Game :: PlayerMove , this); 

m_player = m_jjameMap- >GetPlayerId ( ) ; 

i 

After the game map is loaded, the player entity identifier is obtained through the Map 
class, which stores this information during map loading. 

The next task is getting the camera to follow our hero. This can be accomplished by 
first calling our UpdateCamera method in the Update method of our game state: 

void State_Game :: Update (const sf::Time& l_time) { 

SharedContext* context = mstateMgr- >GetContext ( ) ; 

UpdateCamera ( ) ; 

m_gameMap- >Update (l_time . asSeconds ( ) ) ; 

context- >m_systemManager- >Update ( l_time . asSeconds ( ) ) ; 

} 

The actual UpdateCamera method itself is implemented like so: 

void State_Game :: UpdateCamera () { 
if (m_player == -1) { return; } 

SharedContext* context = mstateMgr- >GetContext ( ) ; 

C_Position* pos = m_stateMgr- >GetContext ( ) - >m_entityManager- > 
GetComponent<C_Position> (m_player , Component: : Position) ; 

m_view . set Center (pos- >GetPosition ()); 

context - >m_wind- >GetRenderWindow ( ) - >setView (m_view) ; 

sf : : FloatRect viewSpace = context - >m_wind- >GetViewSpace () ; 
if (viewSpace . left <= 0) { 

m_view . setCenter (viewSpace . width / 2, m_view . getCenter ( ) . y) ; 
context - >m_wind- >GetRenderWindow ( ) - >setView (m_view) ; 
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} else if (viewSpace . left + viewSpace . width > 
(m_gameMap- >GetMapSize ( ) . x) * Sheet :: Tile_Size) 

{ 

m_view . setCenter ( 

( (m_gameMap- >GetMapSize ( ) . x) * Sheet :: Tile_Size) - 
(viewSpace . width / 2), m_view . getCenter (). y) ; 
context - >m_wind- >GetRenderWindow ( ) - >setView (m_view) ; 

} 


if (viewSpace . top <= 0) { 

m_view . setCenter (m_view . getCenter (). x, viewSpace . height / 2); 
context - >m_wind- >GetRenderWindow ( ) - >setView (m_view) ; 

} else if (viewSpace . top + viewSpace . height > 

(m_gameMap- >GetMapSize ( ) . y) * Sheet :: Tile_Size) 

{ 

m_view . setCenter (m_view . getCenter ( ) . x, 

( (m_gameMap- >GetMapSize ( ) . y) * Sheet :: Tile_Size) - 
(viewSpace . height / 2)); 

context - >m_wind- >GetRenderWindow ( ) - >setView (m_view) ; 



The player identifier first is verified of being a non-negative value, which would 
signify an error. The position component of the player entity is then obtained and 
deals with 

adjusting the view to fit within the boundaries of the map, if it wanders outside of it. 
This is also where the system manager update method must be invoked. 

Drawing our game world also needs revising: 

void State_Game : : Draw ( ) { 

for(unsigned int i = 0; i < Sheet :: Num_Layers ; ++i) { 
m_gameMap- >Draw ( i ) ; 

m_stateMgr- >GetContext ( ) - >m_systemManager- >Draw ( 
m_stateMgr- >GetContext ( ) - >m_wind, i) ; 

} 

} 
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First, a for loop iterates over each layer that might be used in the game. The 
Num_Layers value is part of the Sheet enumeration, which is defined in the Map class 
header. We'll be covering that shortly. The map Draw method now needs to know 
After the 
elevation are 

also rendered on screen, giving the impression of depth in the game, like so: 



Lastly, we need to define the callback method for moving a player: 

void State_Game : : PlayerMove (EventDetails* l_details) { 

Message msg ( (MessageType) EntityMessage : :Move) ; 
if (l_details - >m_name == " Player_MoveLef t " ) { 
msg.m_int = ( int ) Direction :: Left ; 

} else if ( l_details- >m_name == " Player_MoveRight " ) { 
msg.m_int = ( int ) Direction :: Right ; 

} else if ( l_details- >m_name == "Player_MoveUp" ) { 
msg.m_int = ( int ) Direction :: Up ; 

} else if ( l_details- >m_name == " Player_MoveDown" ) { 
msg.m_int = ( int ) Direction :: Down; 

} 

msg . m_receiver = m_player; 

m_stateMgr- >GetContext ( ) - >m_systemManager- > 

GetMessageHandler ( ) - >Dispatch (msg) ; 

1 

A message of type Move is created and set up in order to hold the direction in its 
m int data member. The receiver of the message is also set to be the player, and the 
message is dispatched through the system manager's message handler. This message 
will be handled by one of the systems we'll be building in a later chapter. 
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entity can 

move in. Given the format of our new entity spritesheets, let's modify Directions . h: 

enum class Direction! Up = 0 , Left, Down, Right } ; 

Since the direction is used as a way to offset numbers of rows in sprite sheets for 
all change 

concludes building and setting up the core of our component entity system! All that's 
left now is adjusting the Map class to satisfy and complement the new, shiny features 
of our game. 

The new and improved map 

For as good as the second project of this book looked, a lot of things about it were 
mplexity 

due to its inability to support tile layers. Having a more complex scene requires tiles 
being able to layer over each other, in a manner best represented by this illustration: 



igning the 

way entities are handled requires some changes to be made to the map file format. 
Let's take a look at an example: 

SIZE 32 32 

DEFAULT_FRICTION 1.0 1.0 
| ENTITY | Name | x | y | elevation [ 

ENTITY Player 256.0 256.0 1 

| TILE | ID | x | y | layer | solid | 

TILE 30000 


ound 

're 

making. The main changes here are the entity and tile lines. 
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Loading an entity is as simple as providing the name of its entity file and a few 
pieces of data, relevant to maps, such as its position and elevation. 

Tile loading is also slightly different now. In addition to its identifier and position, 
a tile now also requires having a layer, as well as a flag for solidity, which will be 
covered more in depth in the next chapter. 

Amongst some of the bigger changes, a new value inside the Sheet enumeration is 
defip: 

enum Sheet { 

Tile_Size = 32, Sheet_Width = 256, 

Sheet_Height = 256, NumLayers = 4 

} ; 


Also, in order to allow individual solidity options, each tile now carries a solidity 
flag that can be turned on or off: 

struct Tile{ 

bool m_solid; //Is the tile a solid. 

} ; 


Working with an extra piece of information, the tile layer, requires certain 
modifications to be made to the GetTile and ConvertCoords methods: 

class Map{ 
public : 


Tile* GetTile (unsigned int l_x, unsigned int l_y, 
unsigned int l_layer) ; 

void Draw (unsigned int l_layer) ; 
private : 

unsigned int ConvertCoords (unsigned int l_x, unsigned int l_y, 
unsigned int l_layer) const; 


int m playerld; 


} ; 


Note the m_j? layer Id data member. It keeps track of what entity ID the player has 
been given after loading the map file. 
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Adjusting the Map class 

a look at the 

method used for obtaining map tiles: 

Tile* Map :: GetTile (unsigned int l_x, unsigned int l_y, 
unsigned int l_layer) 

{ 

if (l_x < 0 | | l_y < 0 | | l_x >= m_maxMapSize . x | | 
l_y >= m_maxMapSize . y | | l_layer < 0 | | 
l_layer >= Sheet : :Num_Layers) 

{ 

return nullptr; 

} 

auto itr = m_tileMap . f ind (ConvertCoords (l_x, l_y, l_layer) ) ; 
if (itr == m_tileMap . end ( ) ) { return nullptr; } 
return itr->second; 

} 

t of boundaries 
ts the tile 

layer, which it then passes into the ConvertCoords method. Working with tile layers 
ce we're 

storing all of this information in a one-dimensional array, some additional math 
has to be done in order to perform the conversion: 

unsigned int Map ConvertCoords (unsigned int l_x, 
unsigned int l_y, unsigned int l_layer) const 

{ 

return ( ( l_layer*m_maxMapSize . y+l_y) * m_maxMapSize . x + l_x) ; 

} 

D cube, with 

the layer value representing its depth. 

The desired functionality of the updated Draw method has been outlined quite 
clearly in the game state Draw method. Let's implement that: 

void Map :: Draw (unsigned int l_layer) { 

if (l_layer >= Sheet : :Num_Layers) { return; } 

sf : : RenderWindow* l_wind = m_context- >m_wind- >GetRenderWindow ( ) ; 
sf : : FloatRect viewSpace = m_context->m_wind->GetViewSpace ( ) ; 

sf::Vector2i tileBegin( 

floor (viewSpace . left / Sheet :: Tile_Size) , 
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floor (viewSpace . top / Sheet :: Tile_Size) ) ; 
sf::Vector2i tileEnd( 

ceil ( (viewSpace . left + viewSpace . width) / Sheet :: Tile_Size) , 
ceil ( (viewSpace . top + viewSpace . height) / Sheet :: Tile_Size) ) ; 

unsigned int count = 0; 

for(int x = tileBegin.x; x <= tileEnd.x; ++x) { 
for(int y = tileBegin.y; y <= tileEnd.y; ++y) { 

Tile* tile = GetTile (x, y, l_layer) ; 
if ( ! tile) { continue; } 

sf::Sprite& sprite = tile- >m_properties- >m_sprite ; 
sprite . setPosition (x * Sheet :: Tile_Size , 
y * Sheet :: Tile_Size) ; 
l_wind- >draw ( sprite) ; 

++count ; 

} 

} 

} 

ided layer 

argument does not exceed the defined maximum. Aside from that, the only real 
difference here is that we're passing the layer argument into the GetTile method 
now. That's quite a simple adjustment. 

Lastly, the way tiles and entities are loaded has to be fixed. Let's take a look at 
snippets from the LoadMap method: 

if (type == " TILE " ) { 

sf::Vector2i tileCoords; 
unsigned int tileLayer = 0; 
unsigned int tileSolidity = 0; 
keystream >> tileCoords. x >> tileCoords. y >> 
tileLayer >> tileSolidity; 
if ( tileCoords . x > m_maxMapSize . x | 
tileCoords. y > m__maxMapSize . y | 
tileLayer >= Sheet : :Num_Layers) 

{ 

std::cout << "! Tile is out of range: " << 

tileCoords. x << " " << tileCoords. y << std::endl; 
continue ; 

} 

Tile* tile = new Tile() ; 
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// Bind properties of a tile from a set. 
tile- >m_properties = itr->second; 
tile- >m_solid = (bool) tileSolidity; 
if ( !m_tileMap . emplace (ConvertCoords ( 

tileCoords .x, tileCoords .y, tileLayer) ,tile) .second) 

{ 


} else if ... 

The majority of this code remains unchanged. Reading in the layer and solidity data 
r with the 
t: 

} else if (type == "ENTITY" ) { 

// Set up entity here, 
std: : string name; 
keystream >> name; 

if (name == "Player" && m_playerld != -1) { continue; } 
int entityld = m_context- >m_entityManager- >AddEntity (name) ; 
if (entityld < 0) { continue; } 

if (name == "Player") { m_playerld = entityld; } 

C_Base* position = m_context- >m_entityManager- > 

GetComponent<C_Position> (entityld, Component : : Position) ; 
if (position) { keystream >> *position; } 

} else . . . 

The name of an entity is read in first. If it's a player entity and it hasn't yet been set 
up based on the m_j? layer Id data member, or if it's just any other entity, an attempt 
is made to add it. Upon successfully doing so, its name is checked once more in 
order to make sure the player entity identifier is caught and stored. The position 
file. 
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Once the Map class is finished, compiling and rendering our project and loading in a 



Summary 

With the invention of all the tools we need, we will next be working on adding 
the most common game elements to our final project and bringing it to life, not to 
mention actually flexing the backend functionality we built. Although this chapter 
has come to an end, this is by no means the last of us discovering and applying 
new programming patterns, should a need ever arise again to use one. 

A good code-base is one that can handle new features and expansion of old ones 

mes we make 

venient 

t?" Seeing as 

you have made it this far, why not keep going? See you in the next chapter! 
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A Breath of Fresh Air - Entity 
Component System Continued 

In the previous chapter, we discussed the benefits of using aggregation versus 
simple inheritance. While not necessarily intuitive at first glance, entities composed 
er 

flironment 
states. A 

house is useless without a good foundation, just as much as a good foundation is 
d foundation, 

laying bricks until a proper structure emerges is what's next. 

In this chapter, we will be: 

• Implementing basic movement 

• Developing a system for updating sprite sheets 

• Revisiting and implementing entity states 

• Studying the collision within the entity component system paradigm 


Adding entity movement 

Within the entity component system paradigm, movement of a particular body 
is quantified by all the forces imposed on it. The collection of these forces can be 
represented by a movable component: 

class C_Movable : public C_Base{ 
public : 


private : 

sf::Vector2f m_velocity; 
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float m_velocityMax; 
sf::Vector2f m_speed; 
sf::Vector2f m_acceleration; 

Direction m_direction; 

} ; 

This component takes away physics elements from the second project of this book, 
lify the code, 

the velocity cap is represented by a single float this time, as it is unlikely we will ever 
need to limit the velocity differently based on its axis. 

Let's take a look at the rest of the movable component class: 

C_Movable() : C_Base (Component :: Movable ) , 

m_velocityMax ( 0 . f ) , m_direction ( (Direction) 0 ) 

{} 

, which are 

later replaced by ones from de-serialization: 

void Readln ( std : : stringstreamk l_stream) { 

l_stream >> m_velocityMax >> m_speed.x >> m_speed.y; 

unsigned int dir = 0; 
l_stream >> dir; 
m_direction = (Direction) dir ; 

} 

provide the 
AddVelocity method: 

void AddVelocity (const sf ; : Vector2f & l_vec) { 
m_velocity += l_vec; 

if (std: tabs (m_velocity . x) > m_velocityMax) { 
m_velocity.x = mjvelocityMax * 

(m_velocity . x / std : : abs (m_velocity . x) ) ; 

} 

if (std: :abs (m_velocity . y) > m_velocityMax) { 
m_velocity.y = mjvelocityMax * 

(m_velocity .y / std : : abs (m_velocity . y) ) ; 

} 

} 
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or being 
ty is capped 

at the maximum allowed value with the appropriate sign. 

void ApplyFriction (const sf : : Vector2f & l_vec) { 
if (m_velocity . x ! = 0 && l_vec.x != 0) { 

if (std: tabs (m_velocity.x) - std : : abs ( l_vec . x) < 0) { 
m_velocity.x = 0; 

} else { 

m_velocity.x += (m__velocity .x > 0 ? l_vec.x * -1 : l_vec.x) ; 

} 

} 


if (m_velocity . y ! = 0 && l_vec.y != 0) { 

if (std: tabs (m_velocity.y) - std : : abs ( l_vec . y) < 0) { 
m_velocity.y = 0; 

} else { 

rrwvelocity.y += (m_velocity .y > 0 ? l_vec.y * -1 : l_vec.y) ; 

} 

} 

} 

avoid friction 

forcing the velocity to change its sign, it's checked to not be equal to zero, as well as if 
friction isn't 

going to be negative. If it is, the velocity is set to zero. Otherwise, the friction value is 
added to current velocity with an appropriate sign. 

method for that: 

void Accelerate (const sf : : Vector2f & l_vec) { 
m__acceleration += l_vec; 

} 

void Accelerate ( float l_x, float l_y) { 

m_acceleration += sf : :Vector2f (l_x, l_y) ; 

} 

For the sake of convenience, we provide the same method, overloaded to take in two 
types of arguments: a float vector and two separate float values. All it does is simply 
add the argument values to current acceleration. 
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Lastly, entities can also be moved based on a provided direction, instead of calling 
the Accelerate method manually: 

void Move (const Directions l_dir) { 
if (l_dir == Direction: :Up) { 

m_acceleration . y - = m_speed.y; 

} else if (l_dir == Direction: :Down) { 
m_acceleration . y += m_speed.y; 

} else if (l_dir == Direction :: Left ) { 
m_acceleration.x -= m_speed.x; 

} else if (l_dir == Direction :: Right ) { 
m_acceleration . x += m_speed.x; 

} 

} 

Based on the direction provided as an argument, the entity's speed is added to the 
acceleration vector. 

The movement system 

the actual 

system that will move our entities around: 

enum class Axis{ x, y }; 

class Map; 

class S_Movement : public S_Base{ 

public : 

void SetMap(Map* l_gameMap) ; 

private : 

void StopEntity (const Entitylds l_entity, 
const AxisS l_axis) ; 

void SetDirection (const Entitylds l_entity, 
const Directions: l_dir) ; 

const sf : : Vector2f & GetTileFriction (unsigned int l_elevation, 
unsigned int l_x, unsigned int l_y) ; 
void MovementStep ( float l_dT, C_Movable* l_movable, 

C_Position* l_position) ; 

Map* m_gameMap; 

} ; 
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First, an Axis enumeration is created, in order to simply the code in one of the 
private helper methods of this class. We then forward-declare a Map class, in order 
to be able to use it in the header. With that, comes a Map data member, as well as a 
public method for providing the movement system with an instance of Map. A few 
private helper methods are also needed in order to make the code more readable. 
Let's begin by setting up our constructor: 

S_Movement : : S_Movement (SystemManager* l_systemMgr) 

: S_Base (System: : Movement , l_systemMgr) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : Position) ; 
req . TurnOnBit ( (unsigned int ) Component : :Movable) ; 
m_requiredComponents .push_back (req) ; 
req . Clear ( ) ; 

m_systemManager- >GetMessageHandler ( ) - > 

Subscribe (EntityMessage : : Is_Moving, this) ; 

rn_gameMap = nullptr; 

} 

The requirements for this system consist of two components: position and movable. 
In addition to that, this system also subscribes to the is_Moving message type, 
in order to respond to it. 

Next, let's update our entity information: 

void S_Movement :: Update ( float l_dT) { 
if ( ! m_gameMap ) { return; } 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for(auto kentity : m_entities) { 

C_Position* position = entities-> 

GetComponent<C_Position> (entity, Component: : Position) ; 
C_Movable* movable = entities-> 

Ge t Component <C_Movable> (entity, Component: :Movable) ; 
MovementStep (l_dT, movable, position); 
position- >MoveBy (movable- >GetVelocity ( ) * l_dT) ; 

} 

} 
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position 
gs to this 

system, we want to update its physics and adjust its position in accordance to its 
ent 

based on forces. 

Let's take a look at the movement step method: 

void S_Movement :: Movement Step ( float l_dT, C_Movable* l_movable, 
C_Position* l__position) 

{ 

sf::Vector2f f_coef f icient = 

GetTileFriction (l_position- >GetElevation ( ) , 
f loor (l_position- >GetPosition ( ) . x / Sheet :: Tile_Size) , 
floor (l_position->GetPosition () .y / Sheet :: Tile_Size) ) ; 

sf::Vector2f friction (l_movable- >GetSpeed (). x * f_coeff icient . x, 
l_movable- >GetSpeed ( ) . y * f_coeff icient .y) ; 

l_movable- >AddVelocity ( l_movable- >GetAcceleration ( ) * l_dT); 
l_movable- >Set Acceleration ( sf : : Vector2f (O.Of, 0 . Of ) ) ; 
l_movable->ApplyFriction (friction * l_dT) ; 

float magnitude = sqrt ( 

( l_movable- >GetVelocity ( ) . x * l_movable- >GetVelocity ( ) . x) + 

( l_movable- >GetVelocity ( ) . y * l_movable- >GetVelocity ( ) . y) ) ; 

if (magnitude <= Immovable- >GetMaxVelocity ()) { return; } 
float max_V = l_movable->GetMaxVelocity(); 
l_movable- >SetVelocity ( sf ; : Vector2f ( 

( l_movable- >GetVelocity ( ) . x / magnitude) * max_V, 

( l_movable- >GetVelocity ( ) . y / magnitude) * max_V) ) ; 

} 

The friction value of the tile an entity is standing on is obtained first. It gets applied 
to the entity's movable component right after its velocity is updated based on the 
acceleration value. 
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sider the 

following illustration: 


Chapter 9 



According to the Pythagorean theorem, the squared hypotenuse of a right triangle, 
which represents diagonal movement, is equal to the sum of its squared sides. In 
. Characters 
do in a 
the velocity 
. Once the 

magnitude is calculated, it is checked for exceeding the maximum possible velocity 
of maximum 

velocity, in order to impose slower diagonal movement. 

Obtaining the tile friction can be done like so: 

const sf : : Vector2f& S_Movement : : GetTileFriction ( 

unsigned int l_elevation, unsigned int l_x, unsigned int l_y) 

{ 

Tile* t = nullptr; 

while (!t && l_elevation >= 0) { 

t = m_gameMap- >GetTile (l_x, l_y, l_elevation) ; 

- -l_elevation; 

} 


return (t ? t->m properties- >m friction : 
m_gameMap- >GetDef aultTile ( ) - >m_f riction) ; 


A tile pointer is set up before a while loop is initiated. It will keep trying to fetch a 
is means that 
r is over. If a tile 

hasn't been found, the default friction value is returned instead. 
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nd to 

quite a few events, due to its importance: 

void S_Movement :: HandleEvent (const Entityldk l_entity, 
const EntityEvent& l_event) 

{ 

switch (l_event) { 

case EntityEvent : : Colliding_X : 

StopEntity (l_entity, Axis : :x) ; break; 
case EntityEvent Colliding_Y: 

StopEntity ( l_entity, Axis::y); break; 
case EntityEvent :: Moving_Left ; 

SetDirection ( l_entity , Direction :: Left) ; break; 
case EntityEvent :: Moving_Right : 

SetDirection ( l_entity, Direction :: Right ) ; break; 
case EntityEvent :: Moving_Up : 

{ 

C_Movable* mov = m_systemManager- >GetEntityManager ( ) - > 
GetComponent<C_Movable> (l_entity, Component : :Movable) ; 
if (mov- >GetVelocity ( ) . x == 0) { 

SetDirection ( l_entity, Direction: :Up) ; 

} 

} 

break ; 

case EntityEvent :: Moving_Down : 

{ 

C_Movable* mov = m_systemManager- >GetEntityManager ( ) - > 
GetComponent<C_Movable> (l_entity, Component : :Movable) ; 
if (mov- >GetVelocity ( ) . x == 0) { 

SetDirection ( l_entity, Direction: :Down) ; 

} 

} 

break ; 

} 

} 

the private 

StopEntity method in order to halt an entity on a specified axis. Next, we have 
four movement events. In cases of Moving_Lef t and Moving_Right, the private 
SetDirection method is invoked in order to update the direction of an entity. 
Moving up and down, however, is a little bit different. We want the entity's direction 
to only change if it has no velocity on the x axis. Otherwise, it ends up moving 
rather cheesily. 
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Next up, message handling: 

void S_Movement :: Notify (const Messages; l_message) { 

EntityManager* eMgr = m_systemManager- >GetEntityManager ( ) ; 
EntityMessage m = (EntityMessage) l_message . m_type ; 
switch (m) { 

case EntityMessage :: Is_Moving : 

{ 

if ( ! HasEntity ( l_message . m_receiver ) ) { return; } 

C_Movable* movable = eMgr- >GetComponent<C_Movable> 
(l_raessage.m_receiver, Component: : Movable) ; 
if (movable->GetVelocity ( ) != sf : : Vector2f ( 0 . Of , O.Of)) 

{ 

return; 

} 

m_systemManager- >AddEvent (l_message .m_receiver , 

( Event ID ) EntityEvent : : Became_Idle) ; 

} 

break ; 

} 

} 

Here, we're only concerned with a single message type: is_Moving. It's a message, 
designed to trigger another one being sent when the entity becomes idle. First, the 
nt is then 
iven that that's 

the case, an event is created to signify the entity becoming idle, 
undant logic, 

the existence of which within methods saves us from code duplication. The first one 
we'll examine is responsible for halting an entity: 

void S_Movement :: StopEntity ( const Entityld& l_entity, 
const Axis& l_axis) 

{ 

C_Movable* movable = m_systemManager- >GetEntityManager ( ) - > 
GetComponent<C_Movable> (l_entity, Component : :Movable) ; 
if(l_axis == Axis::x){ 

movable->SetVelocity (sf : : Vector2f ( 

0 . f , movable- >GetVelocity ( ) - y ) ) ; 

} else if (l_axis == Axis::y){ 

movable- >SetVe loci ty ( sf : : Vector2f ( 
movable- >GetVelocity ( ) . x, 0 . f ) ) ; 

} 

} 
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After obtaining its movable component, the entity then has its velocity set to zero on 
an axis, provided as the argument to this method. 

void S_Movement :: SetDirection ( const Entityld& l_entity, 
const Directions^ l_dir) 

{ 

C_Movable* movable = m_systemManager- >GetEntityManager ( ) - > 
GetComponent<C_Movable> (l_entity, Component : :Movable) ; 
movable- >SetDirection (l_dir) ; 

Message msg ( (MessageType) EntityMessage : : Direction_Changed) ; 
msg . m_receiver = l_entity; 
msg.m__int = (int)l_dir; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

1 

The SetDirection method updates the direction of a movable component. A 
e. 

Finally, we're down to a single setter method for the Map class: 

void S_Movement : : SetMap (Map* l_gameMap) { m_gameMap = l_gameMap; } 
to have 

access to the Map class, so it gets set up in the game state: 
void State_Game : : OnCreate ( ) { 

m_stateMgr- >GetContext ( ) - >m_systemManager- > 

GetSystem<S_Movement> (SYSTEM_MOVEMENT) - >SetMap (m_gameMap) ; 

} 

This last code snippet concludes the implementation of the movement system. Our 
entities are now able to move, based on the forces inflicted on them. Having support 
for movement, however, does not actually generate movement. This is where the 
entity state system comes in. 

Implementing states 

Movement, much like many other actions and events that are relevant to entities are 
contingent upon their current state being satisfactory. A dying player should not be 
current 
t: 


enum class EntityState{ Idle, Walking, Attacking, Hurt, Dying }; 
class C_State : public C_Base{ 
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public : 

C_State ( ) : C_Base (Component : : State) { } 
void Readln ( std : : stringstreamk l_stream) { 
unsigned int state = 0; 
l_stream >> state; 
m_state = (EntityState) state ; 

} 


EntityState GetState(){ return m_state; } 
void SetState (const EntityStatek l_state) { 
m_state = l_state; 

} 

private : 

EntityState m_state; 

}; 

As you can tell already, this is a very simple chunk of code. It defines its own 

provides 

on. The rest is, 

as always, left up to the system to hash out. 

The state system 

Since most of the system headers from here on out are going to look pretty much 
the same, they will be omitted. With that said, let's begin by implementing the 
constructor and destructor of our state system: 

S_State : : S_State (SystemManager* l_systemMgr) 

: S_Base (System: : State , l_systemMgr) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : State) ; 
m_requiredComponents .push_back (req) ; 

m_systemManager- >GetMessageHandler ( ) - > 

Subscribe (EntityMessage : :Move,this) ; 
m_systemManager- >GetMessageHandler ( ) - > 

Subscribe (EntityMessage : : Switch_State, this) ; 

} 


[ 265 ] 



A Breath of Fresh Air - Entity Component System Continued 


All this system requires is the state component. It also subscribes to two message 
types: Move and Switch_state. While the latter is self-explanatory, the Move 
ove the 
is the 
state 

is appropriate for motion. 

Next, let's take a look at the Update method: 

void S_State :: Update ( float l_dT) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for(auto kentity : m_entities) { 

C_State* state = entities-> 

GetComponent<C_State> (entity. Component: : State) ; 
if ( state- >GetState ( ) == EntityState :: Walking) { 

Message msg ( (MessageType) EntityMessage : :Is_Moving) ; 
msg . mreceiver = entity; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

} 

} 

} 

f it's in motion, 

a message is_Moving is dispatched. If you recall, this type of message is handled by 
the movement system, which fires an event when the entity becomes idle. That event 
is handled by our state system: 

void S_State :: HandleEvent ( const Entityld& l_entity, 
const EntityEvent& l_event) 

{ 

switch (l_event) { 

case EntityEvent : : Became_Idle : 

Changes t ate ( l_entity , EntityState : : Idle , false) ; 
break ; 

} 

} 

All it does is invoke a private method changestate, which alters the current state 
of an entity to Idle. The third argument here is simply a flag for whether the state 
change should be forced or not. 
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The last public method we'll be dealing with here is Notify: 

void S_State : :Notify (const Message& l_message) { 
if ( ! HasEntity ( l_message . m_receiver ) ) { return; } 

EntityMessage m = (EntityMessage) l_message .m_type; 
switch (m) { 

case EntityMessage :: Move : 

{ 

C_State* state = m_systemManager- >GetEntityManager ( ) - > 
GetComponent<C_State> ( l_message . m_receiver , 

Component; : State) ; 

if (state->GetState ( ) == EntityState :: Dying) { return; } 
EntityEvent e; 

if (lmessage . mint == ( int ) Direction :: Up) { 
e = EntityEvent :: Moving_Up ; 

} else if ( l_message . m_int == ( int ) Direction :: Down) { 
e = EntityEvent ; :Moving_Down; 

} else if ( l_message . m_int == ( int ) Direction :: Left ) { 
e = EntityEvent Moving_Left ; 

} else if ( l_message . m_int == ( int ) Direction :: Right ) { 
e = EntityEvent Moving_Right ; 

} 

m_systemManager- >AddEvent ( l_message . m_receiver , (EventlD)e) ; 
ChangeState (l_message .m_receiver , 

EntityState; : Walking, false) ; 

} 

break ; 

case EntityMessage: ; Switch_State : 

ChangeState ( l_message . m_receiver , 

(EntityState) l_message . m_int , false) ; 
break ; 

} 

} 

The Move message is handled by obtaining the state of an entity it targets. If the 
entity isn't dying, a Moving_x event is constructed based on which direction the 
ed to Walking. 

The SwitchState message simply alters the current state of an entity without 
forcing it, by invoking this private method: 

void S_State :: ChangeState ( const Entityld& l_entity, 
const EntityState& l_state, const bool& l_force) 

{ 
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EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
C_State* state = entities-> 

GetComponent<C_State> (l_entity, Component: : State) ; 
if (!l_force && state- >GetState ( ) == EntityState :: Dying) { 
return; 

} 

state->SetState (l_state) ; 

Message msg ( (MessageType) EntityMessage : : State_Changed) ; 
msg . m_receiver = l_entity; 
msg.m_int = (int) l_state; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

} 

After the state is obtained, the l_f orce flag is checked. If it's set to false, the state 
is only altered if the entity isn't currently DYING. We don't want anything to snap 
if the l_f orce 

flag is set to true. 

ent state. 

With that in place, the entities are now ready to be controlled. 

The entity controller 

tity 

eing moved, 
tations. 

Let's take a look at the controller component: 

class C_Controller : public C_Base{ 
public : 

C_Cont roller ( ) : C_Base (COMPONENT_CONTROLLER) { } 

void Readln ( std : : stringstream& l_stream) { } 

} ; 

the control 

system that the entity it belongs to can be controlled. There might be some additional 
"flag." 

with 

the constructor: 

S_Control : : S_Control (SystemManager* l_systemMgr) 

: S_Base (System : : Control , l_systemMgr ) 

{ 

Bitmask req; 
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req . TurnOnBit ( (unsigned int ) Component : : Position) ; 
req . TurnOnBit ( (unsigned int) Component : : Movable) ; 
req . TurnOnBit ( (unsigned int ) Component : : Controller) ; 
m_requiredComponents .push_back (req) ; 
req. Clear ( ) ; 

} 

It imposes requirements for position, movable and controller components, in order 
to be able to move the entity, which is the only purpose of this system. The actual 
movement is handled by processing entity events like so: 

void S_Control :: HandleEvent ( const Entityld& l_entity, 
const EntityEventk l_event) 

{ 

switch (l_event) { 

case EntityEvent : : Moving_Lef t : 

MoveEntity ( l_entity, Direction : :Left) ; break; 
case EntityEvent :: Moving_Right : 

MoveEntity ( l_entity, Direction :: Right ) ; break; 
case EntityEvent :: Moving_Up : 

MoveEntity ( l_entity, Direction :: Up) ; break; 
case EntityEvent :: Moving_Down : 

MoveEntity ( l_entity, Direction :: Down) ; break; 


} 

All four events invoke the same private method, which simply calls the Move method 
of a movable component and passes in the appropriate direction: 

void S_Control : :MoveEntity (const Entityldk l_entity, 
const Directions^ l_dir) 

{ 

C_Movable* mov = m_systemManager- >GetEntityManager ( ) - > 
GetComponent<C_Movable> (l_entity , Component: :Movable) ; 
mov- >Move ( l_dir ) ; 

} 

After this humble addition to our code-base, we can finally move the player around 
with the keyboard: 
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e to complete 

lack of animations. To resolve this issue, the animation system must be introduced. 

Animating the entities 

If you recall from previous chapters, the SpriteSheet class we built already has 
oint, especially 
a lot of 
, with no 

additional component overhead. 

Let's start implementing the sprite sheet animation system, as always, by getting 
the constructor out of the way: 

S_SheetAnimation : : S_SheetAnimation (SystemManager* l_systemMgr ) 

: S_Base (System: : SheetAnimation, l_systemMgr ) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : SpriteSheet) ; 
req . TurnOnBit ( (unsigned int ) Component : : State) ; 
m_requiredComponents .push_back (req) ; 

m_systemManager- >GetMessageHandler ( ) - > 

Subscribe (EntityMessage : : State_Changed, this) ; 

} 

equires a state 
to the 

state_changed message type in order to respond to state changes by playing the 
appropriate animation. Updating all of the entities is the area where this system 
has most of its logic, so let’s take a look at the Update method: 

void S_SheetAnimation :: Update ( float l_dT) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
forfauto kentity : m_entities) { 

C_SpriteSheet* sheet = entities-> 

GetComponent<C_SpriteSheet> (entity. Component: : SpriteSheet) ; 
C_State* state = entities-> 

GetComponent<C_State> (entity. Component: : State) ; 

sheet->GetSpriteSheet () ->Update (l_dT) ; 

const std::string& animName = sheet-> 

GetSpriteSheet ( ) - >GetCurrentAnim ( ) - >GetName ( ) ; 
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if (animName == "Attack") { 

if ( ! sheet->GetSpriteSheet ( ) - >GetCurrentAnim ( ) ->IsPlaying ( ) ) 

{ 

Message msg ( (MessageType) EntityMessage : : Switch_State) ; 

msg . m_receiver = entity; 

msg.m_int = ( int ) EntityState : : Idle ; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

} else if (sheet->GetSpriteSheet ( ) -> 

GetCurrentAnim ( ) - >IsInAction ( ) ) 

{ 

Message msg ( (MessageType) EntityMessage : : Attack_Action) ; 
msg.m_sender = entity; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

} 

} else if (animName == "Death" && 

! sheet- >GetSpriteSheet ( ) - >GetCurrentAnim ( ) - >IsPlaying ( ) ) 

{ 

Message msg ( (MessageType) EntityMessage : :Dead) ; 
msg . m_receiver = entity; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

} 

} 


te sheet 
n attack 

animation is no longer playing, a message of Switch_state type is sent out in order 
to put the entity back to an idle state. Otherwise, the animation is checked for 
currently being within the "action" frame range, which is specified in the sprite sheet 
file. If it is, an Attack_Action message is sent out to the current entity, which can 
d, if the 

death animation has concluded, a Dead message is dispatched. 

Next, let's work on handling messages: 

void S_SheetAnimation :: Notify ( const Messages; l_message) { 
if (HasEntity ( l_message . m_receiver ) ) { 

EntityMessage m = (EntityMessage) l_message .m_type; 
switch (m) { 

case EntityMessage: : State_Changed : 

{ 

EntityState s = (EntityState) l_message . m_int ; 
switch (s) { 

case EntityState :: Idle : 
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ChangeAnimation ( l_message . m_receiver , " Idle" , true, true) ; 
break ; 

case EntityState :: Walking : 

ChangeAnimation ( l_message . m_receiver , "Walk" , true, true) ; 
break ; 

case EntityState :: Attacking : 

ChangeAnimation ( l_message . m_receiver , 

"Attack" , true, false) ; 
break ; 

case EntityState :: Hurt : break; 
case EntityState Dying ; 

ChangeAnimation ( l_message . m_receiver , 

"Death" , true, false) ; 
break ; 

} 

} 

break ; 

} 

} 

} 

All possible messages this system would be interested in deal with specific entities, 
so that check is made first. For now, we'll only be dealing with a single message 
type: state_Changed. Every time a state is changed, we'll be altering the animation 
of the entity. The only possible exception here is the Hurt state, which will be dealt 
with later. 

The last bit of code we need is the private ChangeAnimation method: 

void S_SheetAnimation: : ChangeAnimation (const Entityldk l_entity, 
const std : : strings l_anim, bool l_play, bool l_loop) 

{ 

C_SpriteSheet* sheet = m_systemManager- >GetEntityManager ( ) - > 
GetComponent<C_SpriteSheet> (l_entity, Component : : SpriteSheet) ; 
sheet - >GetSpriteSheet ( ) - >SetAnimation ( l_anim, l_play , l_loop) ; 

} 

After obtaining the entity's sprite sheet component, it simply invokes its 
Set Animat ion method to change the current animation that's playing. 

This code is redundant enough to warrant a separate method. 
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Upon successful compilation, we can see that our entities are now animated: 



Handling collisions 

onments we'll 

be able 

ming around 

ing boxes 

constructing the 

collidable body component: 

enum class Origin{ Top_Left, Abs_Centre, Mid_Bottom }; 

class C_Collidable : public C_Base{ 
public : 

private : 

sf : : FloatRect m_AABB; 
sf::Vector2f m_offset; 

Origin m_origin; 

bool m_collidingOnX; 
bool m_collidingOnY; 

} ; 


Every collidable entity must have a bounding box that represents the solid portion 
of it. That's exactly where the m_AABB rectangle comes in. In addition to that, the 
bounding box itself can be offset by a number of pixels, based on what kind of 
entity it is, as well as have a different origin. Lastly, we want to keep track of 
whether an entity is currently colliding on any given axis, which warrants the 
use of m_collidingOnX and m_collidingOnY flags. 

s: 


C_Collidable ( ) : C_Base (Component : : Collidable) , 

m_origin (Origin : :Mid_Bottom) , m_collidingOnX (false) , 
m_collidingOnY (false) 

{} " 
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component, 

like many others, needs to have a way to be de-serialized: 

void Readln ( std : : stringstreamk l_stream) { 
unsigned int origin = 0; 

l_stream >> m_AABB . width >> m_AABB . height >> m_offset.x 
>> m_offset.y >> origin; 
m_origin = (Origin) origin; 

} 

Here are a few unique setter and getter methods that we'll be using: 

void CollideOnX ( ) { m_collidingOnX = true; } 
void CollideOnY ( ) { m_collidingOnY = true; } 
void ResetCollisionFlags ( ) { 
m_collidingOnX = false; 
m_collidingOnY = false; 

} 

void SetSize (const sf : : Vector2f & l_vec) { 
m_AABB . width = l_vec.x; 

m_AABB . height = l_vec . y ; 

} 

Finally, we arrive at the key method of this component, SetPosition: 

void SetPosition (const sf ; : Vector2f & l__vec) { 
switch (m_origin) { 
case (Origin: :Top_Left) : 

m_AABB.left = l_vec.x + m offset. x; 
m_AABB . top = l_vec.y + m_offset.y; 
break ; 

case (Origin: :Abs_Centre) : 

m_AA.BB.left = l_vec.x - (m_AABB . width / 2) + m_offset.x; 
m_AABB . top = l_vec.y - (m_AABB . height / 2) + m_offset.y; 
break ; 

case (Origin: :Mid_Bottom) : 

m_AABB.left = l_vec.x - (m_AABB . width / 2) + m_offset.x; 
m_AABB . top = l_vec.y - m_AABB . height + m_offset.y; 
break ; 

} 

} 
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ding box 

rectangle must be set differently. Consider the following illustration: 



The origin of the actual bounding box rectangle is always going to be the top-left 
ate for 

differences between several possible origin types. 

The collision system 

The actual collision magic doesn't start happening until we have a system responsible 
for accounting for every collidable body in the game. Let's begin by taking a look at the 
data types that are going to be used in this system: 

struct CollisionElement { 

CollisionElement (float l_area, Tilelnfo* l_info, 
const sf : :FloatRect& l_bounds) : m_area ( l_area) , 
m_tile (l_info) , m_tileBounds (l_bounds) { } 
float m_area; 

Tilelnfo* m_tile; 

sf : : FloatRect m_tileBounds ; 

} ; 


using Collisions = std : : vector<CollisionElement> ; 

data structure 
ted and 

processed. For that, we're going to be using a vector of CollisionElement data 
types. It's a structure, consisting of a float, representing area of collision, a pointer 
to a Tilelnfo instance, which carries all of the information about a tile, and a 
simple float rectangle, which holds the bounding box information of a map tile. 

system needs to 

have access to a Map instance. Knowing all of that, let's get started on implementing 
the class! 
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Implementing the collision system 

As always, we're going to be setting up the component requirements right inside the 
constructor of this class: 

S_Collision: : S_Collision (SystemManager* l_systemMgr) 

:S_Base (System: :Collision, l_systemMgr) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : Position) ; 
req . TurnOnBit ( (unsigned int ) Component : : Collidable) ; 
m_requiredComponents .push_back (req) ; 
req . Clear ( ) ; 

m_gameMap = nullptr; 

} 

As you can see, this system imposes requirements of position and collidable 
components on entities. Its m_gameMap data member is also initialized to nullptr, 
until it gets set up via the use of this method: 

void S_Collision : : SetMap (Map* l_map) { m_gameMap = l_map; } 


S 

it should: 

void S_Collision :: Update ( float l_dT) { 
if ( ! m_gameMap ) { return; } 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for(auto kentity : m_entities) { 

C_Position* position = entities-> 

GetComponent<C_Position> (entity, Component: : Position) ; 
C_Collidable* collidable = entities-> 

GetComponent<C_Collidable> (entity , Component: :Collidable) ; 
collidable- >SetPosition (position- >GetPosition ( ) ) ; 
collidable- >ResetCollisionFlags ( ) ; 

CheckOutOf Bounds (position, collidable) ; 

MapCollisions (entity, position, collidable) ; 

} 

EntityCollisions ( ) ; 

} 
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For clarity, the update method uses two other helper methods: CheckOutOf Bounds 
and MapCollisions. While iterating over all collidable entities, this system obtains 
e entity's 

latest position. It also has its Boolean collision flags reset. After all entities have been 
updated, the private EntityCollisions method is invoked to process entity-on- 
entity intersection tests. Note the very beginning of this method. It immediately 
returns in case the map instance hasn't been properly set up. 

First, the entity is checked for being outside the boundaries of our map: 

void S_Collision : : CheckOutOfBounds (C_Position* l_pos, 

C_Collidable* l_col) 

{ 

unsigned int TileSize = m_gameMap- >GetTileSize ( ) ; 

if (l_pos->GetPosition ( ) .x < 0){ 

l_pos->SetPosition (0 . Of , l_pos- >GetPosition ( ) .y) ; 
l_col->SetPosition (l_pos- >GetPosition ( ) ) ; 

} else if (l_pos->GetPosition() .x > 
m_gameMap- >GetMapSize ( ) . x * TileSize) 

{ 

l_pos- >SetPosition (m_gameMap- >GetMapSize ( ) . x * TileSize, 
l_pos->GetPosition ( ) .y) ; 
l_col->SetPosition (l_pos- >GetPosition ( ) ) ; 

} 

if (l_pos->GetPosition ( ) .y < 0){ 

l_pos->SetPosition (l_pos- >GetPosition ( ) .x, O.Of) ; 
l_col->SetPosition (l_pos- >GetPosition ( ) ) ; 

} else if (l_pos->GetPosition() .y > 
m_gameMap- >GetMapSize ( ) . y * TileSize) 

{ 

l_pos->Set Posit ion ( l_pos- >Get Posit ion ( ) .x, 
m_gameMap- >GetMapSize ( ) .y * TileSize); 
l_col->SetPosition (l_pos- >GetPosition ( ) ) ; 

} 

} 


set. 
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At this point, we begin running the tile-on-entity collision test: 

void S_Collision :: MapCollisions ( const Entityld& l_entity, 
C_Position* l_pos, C_Collidable* l_col) 

{ 

unsigned int TileSize = m_gameMap- >GetTileSize ( ) ; 

Collisions c; 

sf : : FloatRect EntityAABB = l_col - >GetCollidable ( ) ; 
int FromX = floor (EntityAABB . left / TileSize); 

int ToX = floor ( (EntityAABB . left + EntityAABB .width) /TileSize) ; 
int FromY = floor (EntityAABB . top / TileSize); 

int ToY = floor ( (EntityAABB . top + EntityAABB .height) /TileSize); 


} 

A collision information vector named c is set up. It will contain all the important 
information about what the entity is colliding with, the size of the collision area and 
properties of the tile it's colliding with. The entity's bounding box is then obtained 
from the collidable component. A range of coordinates to be checked is calculated, 
based on that bounding box, as shown here: 



Those coordinates are immediately put to use, as we begin iterating over the 
calculated range of tiles, checking for collisions: 

for (int x = FromX; x <= ToX; ++x) { 
for (int y = FromY; y <= ToY; ++y) { 

for (int 1 = 0; 1 < Sheet: :Num_Layers; ++1) { 

Tile* t = m_gameMap- >GetTile (x, y, 1) ; 

if ( ! t ) { continue; } 

if ( ! t- >m_solid) { continue; } 

sf :: FloatRect TileAABB (x*TileSize , y*TileSize, 

TileSize, TileSize) ; 
sf :: FloatRect Intersection; 

EntityAABB . intersects (TileAABB, Intersection) ; 
float S = Intersection . width * Intersection . height ; 
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c . emplace_back (S , t- >m_properties , TileAABB) ; 
break ; 



} 

area of 

intersection details are gathered and inserted into the vector c. It's important to 
ection may not 
function properly. 

ve been found, 
they all must be sorted: 

if (c.empty()){ return; } 
std: : sort (c . begin () , c . end ( ) , 

[] (CollisionElement& 1_1, CollisionElement& 1_2){ 
return l_l.m_area > l_2.m_area; 

}>; 

After sorting, we can finally begin resolving collisions: 

for (auto &col ; c) { 

EntityAABB = l_col - >GetCollidable ( ) ; 

if (! EntityAABB . intersects (col . m_tileBounds )) { continue; } 
float xDiff = (EntityAABB . left + (EntityAABB . width / 2)) - 

(col . m_tileBounds . left + ( col . m_tileBounds . width / 2)); 
float yDiff = (EntityAABB . top + (EntityAABB . height / 2)) - 

(col . m_tileBounds . top + (col . m_tileBounds . height / 2)); 
float resolve = 0; 

if (std: : abs (xDiff ) > std: : abs (yDiff )) { 
if (xDiff > 0) { 

resolve = (col . m_tileBounds . left + TileSize) - 
EntityAABB . left ; 

} else { 

resolve = -( (EntityAABB . left + EntityAABB . width) - 
col . m_tileBounds . left ) ; 

} 

l_pos->MoveBy (resolve, 0); 
l_col->SetPosition (l_pos- >GetPosition ( ) ) ; 
m_sys t emManage r - >AddEvent ( l_ent i ty , 

(EventID) EntityEvent : : Colliding_X) ; 
l_col->CollideOnX ( ) ; 

} else { 

if (yDiff > 0) { 

resolve = (col . m_tileBounds . top + TileSize) - 
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EntityAABB . top ; 

} else { 

resolve = -( (EntityAABB . top + EntityAABB . height ) - 

col .m_tileBounds . top) ; 

} 

1 pos- >MoveBy ( 0 , resolve); 
l_col->SetPosition (l_pos- >GetPosition ( ) ) ; 
m_systemManager- >AddEvent (l_entity , 

(EventID) EntityEvent : ; Colliding_Y) ; 
l_col->CollideOnY ( ) ; 

} 

} 

Since resolution of one collision could potentially resolve another as well, the 
bounding box of an entity must be checked for intersections here as well, before we 
it was in 

Chapter 7 , Rediscovering Fire - Common Game Design Elements. 

Once the resolution details are calculated, the position component is moved based 
it would 
The last 

bit we need to worry about is adding a collision event to the entity's event queue 
and calling the CollideOnX or CollideOnY method in the collidable component 
to update its flags. 

Now for entity-on-entity collisions: 

void S_Collision: : EntityCollisions ( ) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
forfauto itr = m_entities . begin () ; 
itr != m_entities . end ( ) ; ++itr) 

{ 

for (auto itr2 = std :: next ( itr ) ; 

itr2 != m entities . end () ; ++itr2){ 

C_Collidable* collidablel = entities-> 

GetComponent<C_Collidable> (*itr, Component: : Collidable) ; 
C_Collidable* collidable2 = entities-> 

GetComponent<C_Collidable> (*itr2 , Component: : Collidable) ; 
if (collidablel- >Get Collidable ( ) . intersects ( 
collidable2->GetCollidable ( ) ) ) 

{ 

// Entity-on-entity collision! 

} 

} 

} 

} 
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This method checks all entities against all other entities for collisions between their 
bounding boxes, by using the intersects method, kindly provided by SFML's 
se types 
apters. 

s a pointer 

to the Map class, so let's give it one in the game state's OnCreate method: 
void State_Game :: OnCreate () { 

m_stateMgr- >GetContext ( ) - >m_systemManager- > 

GetSystem<S_Collision> (SYSTEM_COLLISION) - >SetMap (m_gameMap) ; 


} 

This final code snippet gives the collision system all of the power it needs, in order 
to keep the entities from walking through solid tiles, as so: 



Summary 

Upon completing this chapter, we've successfully moved away from inheritance- 

based entity design and reinforced our code-base with a much more modular 

chain 

the entity 

segment will hold. 

In the next two chapters, we will be discussing how to make the game more interactive 
and user friendly by adding a GUI system, as well as adding a few different types 
of elements, managing their events and providing room for them to be graphically 
customizable. See you there! 
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Can I Click This? -GUI 

Fundamentals 


What do humans and machines really have in common, in the non-Turing sense of 
s almost 
as 

s we use, 
can't learn 
consuming 

as our brains work in a completely different way to a common processor. A gray 

n also be 

involved 

with the underlying complexities - the means of interfacing. 

In this chapter, we will cover the following topics: 

• Implementation of core data types for all GUI elements 

• Utilizing SFML's render textures to achieve GUI layering 

• Laying down the fundamentals of smooth and responsive GUI interactions 
by using stylistic attributes 

There is quite a bit of ground to cover so let's get started! 
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Use of copyrighted resources 

Before we begin, it's only fair to credit the true creators of the fonts and images used 
in the next two chapters: 

Fantasy UI Elements by Ravenmore at http : //dycha . net/ under the 
CC-BY 3.0 license: 

http : //opengameart . org/ content/ f antasy-ui- elements -by- ravenmore 

Vegurfont by Arro under the CCO license (public domain): 

http : //www . f ontspace . com/ arro/vegur 

can be 
found here: 

http : / / creativecommons . org/publicdomain/ zero/ 1 . 0/ 
http : // creativecommons . org/licenses/by/ 3.0/ 


What is a GUI? 

A GUI, short for Graphical User Interface, is a visual intermediary between the user 
and a piece of software which serves as a control mechanism for digital devices or 
n relying on 

text-based controls, such as typing commands, 
ur GUI 

system, which is going to consist of three major components: 

• Element: Every GUI surface that is drawn onto the screen 

• Interface: A special kind of element that serves as a container for other 
elements and can be moved around as well as scrolled 

• Manager: The class that is in charge of keeping GUI interfaces in line 
and behaving 

nt state when 
be applied to 
ou must be able 

to load the interfaces from files at runtime and tie them to code based on an event or 
a set of events taking place within them. 
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GUI style 

if you need 

customization and flexibility. To put it simply, modifying and applying every single 
stylistic attribute of every possible type of element manually would be a nightmare 
and any kind of code re-use would be impossible. This calls for a custom data type 
that can be used all across the board: the GUi_style structure. 

First things first, any and all GUI elements should be able to support the three 
following states: 

enum class GUI_ElementState { Neutral, Focused, Clicked }; 

e of them is 

also defined as a set of visual properties in order to simulate interaction and fluidity, 
represented by a set of style attributes: 

struct GUI_Style{ 

sf::Vector2f m_size; // Element size. 

// Background properties. 
sf::Color m_backgroundColor ; 
sf::Color m_elementColor ; 
std: : string m_backgroundImage ; 
sf : :Color m_backgroundImageColor ; 

// Text properties. 
sf::Color m_textColor; 
std:: string m_textFont; 
sf::Vector2f m_textPadding; 
unsigned int m_textSize; 
bool m_textCenterOrigin; 

// Glyph properties. 
std::string m_glyph; 
sf::Vector2f m_glyphPadding ; 

} ; 


nd adjust itself 
defined, the 

default values set in the constructor take precedence, as shown here: 

GUI_Style(): m_textSize ( 12 ) , m_textCenterOrigin (false) , 


m__backgroundImageColor (255 , 255 , 255 , 255) 

{ 


sf : : Color none 

= sf::Color(0, 0 , 0, 0 

m backgroundColor 

= none; 

m elementColor 

= none; 

m textColor 

= none; 


} 
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All of this is useless if we don't have drawable objects to modify, so let's fix that: 
struct GUI_Visual{ 

sf : : RectangleShape m_backgroundSolid; 
sf : : Sprite m_backgroundImage ; 
sf:: Sprite m_glyph; 
sf : : Text m_text ; 

} ; 


e allowing 
s. 

Expansion of utility functions 

to create 

utility-type functions out of any code that is going to be used frequently. When 

arameters 

ing in double 

quotes and defi 

the Utilities . h file: 

inline void ReadQuotedString ( std : : stringstream& l_stream, 
std: : strings l_string) 

{ 

l_stream >> l_string; 
if (l_string . at ( 0 ) == 

while ( l_string . at ( l_string . length ( ) - 1) != | j 

! l_stream. eof ( ) ) 

{ 

std:: string str; 
l_stream >> str; 
l_string . append ( " " + str); 

} 

} 

l_string . erase ( std : : remove ( l_string . begin ( ) , 
l_string . end ( ) , l_string . end ( ) ) ; 

} 

A word is loaded from the string stream object into the string provided as an 
argument. Its first character is checked to see if it is a double quote. If it is, a while 
1 either 


Following that, all of the double quotes in the string are erased. 
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Font management 

we need a way 
ust like 

we did with textures. The effort we put into the resource manager written back in 
Chapter 6, Set It in Motion! - Animating and Moving around Your World, is about to pay 
off. In order to manage fonts, all we need to do is create a FontManager . h file and 
write the following code: 

class FontManager : public ResourceManager<FontManager , sf::Font>{ 
public : 

FontManager ( ) : ResourceManager (" fonts . cfg" ){ } 

sf::Font* Load(const std : : string^ l_path) { 
sf::Font* font = new sf::Font(); 
if ( ! f ont - >loadFromFile ( 

Utils :: GetWorkingDirectory ( ) + l_path) ) 

{ 

delete font; 
font = nullptr; 

std::cerr << "! Failed to load font: " 

<< l_path << std::endl; 

} 

return font; 

} 

} ; 


This defines the font resource configuration file in the constructor, as well as the 
specific way of loading font files using the Load method. The resource manager class 
P going 1 


The core of all elements 

The GUi_Element class is the core of every single element and interface. It provides key 
functionality that higher level objects rely on, as well as enforcing the implementation 
of necessary methods, which leads to several distinctive element types. 

A definition of the different element types is a good place to start: 

enum class GUI_ElementType{ Window, Label, Button, Scrollbar, 

Textfield }; 
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state. The 

unordered_map data structure suits our purposes pretty well: 

using ElementStyles = std: : unordered_map< 

GUI_ElementState , GUI_Style>; 

A forward declaration of the owner class is also necessary to prevent cross-inclusion: 
class GUI_Interf ace ; 

Next, we can begin shaping the GUl_Element class: 

class GUI_Element{ 

friend class GUI_Interf ace ; 
public : 

GUI_Element (const std :: strings l_name, 

const GUI_ElementType& l_type, GUI_Interf ace* l_owner) ; 
virtual ~GUI_Element ( ) ; 

/ / Event methods . 

virtual void Readln ( std :: stringstreamk l_stream) = 0; 
virtual void OnClick (const sf : : Vector2f & l_mousePos) = 0; 
virtual void OnReleaseO = 0; 

virtual void OnHover (const sf : : Vector2f & l_mousePos) = 0; 

virtual void OnLeave ( ) = 0; 

virtual void Update (float l_dT) = 0; 

virtual void Draw ( sf : : RenderTarget* l_target) = 0; 

virtual void UpdateStyle (const GUI_ElementState& l_state, 
const GUI_Style& l_style) ; 
virtual void ApplyStyle ( ) ; 

... // Getters/setters 

friend std : : stringstream& operator >> ( 

std : : stringstream& l_stream, GUI_Element& b) 

{ 

b . Readln ( l_stream) ; 
return l_stream; 

} 

protected: 

void ApplyTextStyle ( ) ; 
void ApplyBgStyle ( ) ; 
void ApplyGlyphStyle ( ) ; 

void RequireTexture ( const std::string& l_name) ; 
void RequireFont (const std : : strings l_name) ; 
void ReleaseTexture ( const std::string& l_name) ; 
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void ReleaseFont (const std : : strings, l_name) ; 
void ReleaseResources ( ) ; 
std: : string m_name; 
sf::Vector2f m_position; 

ElementStyles m_style; // Style of drawables. 

GUI_Visual m_visual; // Drawable bits. 

GUI_ElementType m_type ; 

GUI_ElementState m_state; 

GUI_Interf ace* m_owner; 

bool m_needsRedraw; 
bool m_active; 
bool m_isControl; 

}; 

The most essential part of any GUI element is how it responds to events. This is 
ods, 

differently 

to a default element. 

Every element also needs to have a name, a position, a set of styles for every possible 
state, a visual component that can be drawn, a type and state identifiers, and a pointer 
to an owner class. It also needs to keep track of whether it needs to be re-drawn, its 
active status, and a flag that denotes whether it is a control or not. These properties 
are represented by a set of private data members of the GUi_Element class. 

With a rough idea of this structure hammered out, let's shape the finer details of the 
element class. 

Implementing the GUI element class 

The class we're about to begin implementing is a cornerstone of every single interface 
and element. It will define how our GUI system behaves. With that in mind, let's 
start by taking a look at the constructor, as we have quite a bit to initialize: 

GUI_Element :: GUI_Element (const std :: strings, l_name , 

const GUI_ElementTypeS, l_type, GUI_Interf ace* l_owner) 

: m_name ( l_name ) , m_type ( l_type ) , m_owner ( l_owner ) , 
m_state (GUI_ElementState : :Neutral) , m_needsRedraw (false) , 
m_active (true) , m_isControl (false) { } 
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aken in and 

passed to the appropriate data members. Other additional flags are also initialized to 

ke a look at how 

this class is destroyed: 

GUI_Element : : ~GUI_Element () { ReleaseResources () ; } 

Since there is no dynamic memory allocation going on anywhere in this class, 
releasing resources is also fairly simple. The method for that specific purpose is 
simply invoked here. It looks a little like this: 

void GUI_Element: : ReleaseResources ( ) { 
for (auto &itr : m_style) { 

ReleaseTexture ( itr . second . m_backgroundImage) ; 

ReleaseTexture (itr . second . m_glyph) ; 

ReleaseFont ( itr . second . m_textFont ) ; 

} 

} 

required by 
released by the 

respective methods, which all look similar to the one shown: 

void GUI_Element :: ReleaseTexture (const std::string& l_name) { 
if (l_name == ""){ return; } 
m_owner- >GetManager ( ) - >GetContext ( ) - > 

m_textureManager- >ReleaseResource (l_name) ; 

} 

used. 

he 

UpdateStyle method takes care of that job: 

void GUI_Element UpdateStyle ( const GUI_ElementState& l_state, 
const GUI_Style& l_style) 

{ 

// Resource management, 
if (l_style . m_backgroundImage != 

m_style [l_state] .m_backgroundImage) 

{ 

ReleaseTexture (m_style [l_state] .m_backgroundImage) ; 

RequireTexture (l_style .m_backgroundImage) ; 

} 
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if (l_style .m_glyph != m_style [l_state] .m_glyph) { 
ReleaseTexture (m_style [l_state] .m_glyph) ; 
RequireTexture ( l_style . m_glyph) ; 

} 


if ( l_style . m_textFont != m_style [l_state] . m_textFont ) { 
ReleaseFont (m_style [l_state] .m_textFont) ; 

RequireFont (l_style .m_textFont) ; 

} 

// Style application. 
m_style [l_state] = l_style; 

if (l_state == m_state) { SetRedraw (true) ; ApplyStyle ( ) ; } 

} 

Two arguments are expected by this method: the state being modified and a style 
structure that will be used to replace the existing structure. While overwriting 
esource 

management has to take place before that happens. We need to know if the style 
, the older 
g two 

more helper methods which both look something like this: 

void GUI_Element :: RequireTexture (const std::string& l_name) { 
if (l_name == ""){ return; } 
m_owner- >GetManager ( ) - >GetContext ( ) - > 

m_t extureManager - >RequireResource (l_name) ; 

} 

rwise 

identical. 

Once the style is overwritten, we check if the state being modified is the same 
drawn via the 

SetRedraw method, and its style is applied via the ApplyStyle method, which is 
what we'll take a look at next: 

void GUI_Element : : ApplyStyle ( ) { 

ApplyTextStyle ( ) ; 

ApplyBgStyle () ; 

ApplyGlyphStyle ( ) ; 

if (m__owner != this && ! IsControl ( ) ) { 
m_owner- >Ad just Content Size ( this ) ; 

} 

} 
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This chunk of code is responsible for connecting the style of an element to its visual 
representation. It first invokes a few helper methods which help us break down 
to be 

alerted afterwards because any modification of the element style may result in 
wn owner, the 

AdjustContentSize method of the GUI_Interf ace class is called, with the this 
keyword passed in as an argument. We will get to implement it soon. 

Let's take a look at the first helper method, which deals with text style: 

void GUI_Element : : ApplyTextStyle ( ) { 

FontManager* fonts = m^owner- >GetManager ( ) - > 

GetContext ( ) - >m_f ontManager ; 
const GUI_Style& CurrentStyle = m_style [m_state] ; 
if (CurrentStyle .m_textFont != ""){ 
m_visual . m_text . setFont ( 

♦fonts- >GetResource (CurrentStyle . m_textFont ) ) ; 
m_visual . m_text . setColor (CurrentStyle . m_text Color ) ; 
m_visual . m_text . setCharacterSize (CurrentStyle .m_textSize) ; 
if (CurrentStyle . m_textCenterOrigin) { 

sf : : FloatRect rect = m_visual . m_text . getLocalBounds ( ) ; 
m_visual . m_text . setOrigin ( rect . lef t + rect. width / 2. Of, 
rect. top + rect. height / 2. Of); 

} else { 

m_visual . m_text . setOrigin ( 0 . f , 0 . f ) ; 

} 

} 

m_visual . m_text . setPosition (m position + 

CurrentStyle . m_textPadding) ; 

} 

or each distinct 
lculated every 

time this happens because these attributes can be manipulated at any point. The 
position of the text is then updated with the padding value of the current style 
being factored in. 

Background style application follows the same basic idea: 

void GUI_Element : : ApplyBgStyle ( ) { 

TextureManager* textures = mjowner- >GetManager ( ) - > 

GetContext () - >m_t extureManager ; 
const GUI_Style& CurrentStyle = m_style [m_state] ; 
if (CurrentStyle . m_backgroundImage != ""){ 
m_visual . m_backgroundImage . setTexture ( 


[ 292 ] 



Chapter 10 


*textures->GetResource (CurrentStyle .m_backgroundImage) ) ; 
m_visual . m_backgroundImage . setColor ( 

CurrentStyle . m_backgroundImageColor ) ; 

} 

m_visual . m_backgroundImage . setPosition (m_position) ; 
m_visual . m_backgroundSolid . setSize ( 
sf : : Vector2f (CurrentStyle .m_size) ) ; 
m_visual . m_backgroundSolid . setFillColor ( 

CurrentStyle . m_backgroundColor ) ; 
m_visual . m_backgroundSolid . setPosition (m_position) ; 

} 

This shows how we add support for the background image and solid elements. Both 
of these elements are adjusted by applying the visual attributes of a current style and 
having their positions re-set. 

Finally, the glyph of an element is altered in the same fashion: 

void GUI_Element : : ApplyGlyphStyle ( ) { 

const GUI_Style& CurrentStyle = m_style [m_state] ; 

TextureManager* textures = mjowner- >GetManager ( ) - > 

GetContext ( ) - >m_textureManager ; 
if (CurrentStyle . m_glyph != ""){ 
m_visual . m_glyph . setTexture ( 

‘textures - >GetResource (CurrentStyle .m_glyph) ) ; 

} 

m_visual . m_glyph . setPosition (m_position + 

CurrentStyle . m_glyphPadding) ; 

1 

Next, let's take a look at the changing element states: 

void GUI_Element :: SetState (const GUI_ElementState& l_state) { 
if (m_state == l_state) { return; } 
m_state = l_state; 

SetRedraw (true) ; 

} 

ferent states 
done if the 
done to 

conserve resources. 
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Setting the element position also deserves some attention: 

void GUI_Element :: SetPosition (const sf : : Vector2f& l_pos){ 
m_position = l_pos; 

if (m__owner == nullptr | | m_owner == this) { return; } 
const auto& padding = m_owner- >GetPadding ( ) ; 
if (m position.x < padding. x) { m_position.x = padding. x; } 
if (m_position . y < padding. y) { m_position.y = padding. y; } 

} 

ust also 
the padding 
r axis is less 

than that padding, the position is set to be at least as far away from the edge as the 
interface allows it to be. 

any 

GUI surface: 

bool GUI_Element :: Islnside (const sf : : Vector2f & l_point) const{ 
sf::Vector2f position = GetGlobalPosition () ; 
return (l_point . x >= position.x && 
l_point.y >= position. y && 

l_point.x <= position.x + m_style . at (m_state) .m_size .x && 
l_point.y <= position. y + m_style . at (m_state) ,m_size .y) ; 

} 

The Islnside 
ncorrect 

results because of its relativity to its owner. Instead, it uses a GetGlobalPosition 
method to fetch the element's position in screen space, as opposed to local space, in 
the render texture of the owner interface. With a bit of basic bounding box collision 
he element, 

based on the size of its current style. 

Obtaining global positions of elements can be done like so: 

sf::Vector2f GUI_Element GetGlobalPosition ( ) const{ 
sf::Vector2f position = GetPosition ( ) ; 

if (m_owner == nullptr | | m_owner == this) { return position; } 

position += m_owner- >GetGlobalPosition ( ) ; 

if ( IsControl ( ) ) { return position; } 

position.x -= m_owner- >m_scrollHorizontal ; 

position. y -= m_owner->m_scrollVertical ; 

return position; 

} 
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Firstly, the element's local position is grabbed. The method then determines if this 
element has an owner and if does not own itself. If it does, the fetched position 
is simply the final result and is returned. Otherwise, the owner's global position 
osition. 
rtical scroll 
Uing. 

ghtforward: 

Const sf : : Vector2f & GUI_Element : :GetSize ( ) const{ 
return m_style . at (m_state) .m_size; 

} 

void GUI_Element :: SetActive ( const bool& lactive) { 
if (l_active != m_active) { 
m_active = l_active; 

SetRedraw (true) ; 

} 

} 

std: : string GUI_Element : : GetText ( ) const { 
return m_visual . m_text . getString ( ) ; 

} 

void GUI_Element :: SetText (const std::string& l_text) { 
m_visual ,m_text . setstring (l_text) ; 

SetRedraw (true) ; 

} 

Note the methods SetActive and SetText. Whenever an element is 
modified, we must set its re-draw flag to true, otherwise it won't be 
updated until another event requires it. 



Defining GUI events 

Providing fluid interactivity with the interface and a painless way of associating 
riterion to 

separate good GUI systems from bad ones. As we are already learning SFML, we can 
use the SFML method and omit events. 

Firstly, we have to define all the possible events that could take place in an interface. 
Create a GUi_Event . h file and construct an enumeration, as shown here: 

enum class GUI_EventType { None, Click, Release, Hover, Leave } ; 
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We must also define a custom structure in the same file that is used to hold event 
information: 


struct ClickCoordinates { 
float x, y; 

in- 


struct GUI_Event{ 

GUI_EventType m_type; 
const char* m_element; 
const char* m_interface; 
union { 

ClickCoordinates m_clickCoords ; 

} ; 

} ; 


The first thing to talk about here is the structure. It should be possible to merely use 
sf : : Vector2 f here. That would work fine under most circumstances but, a few 
lines below that, you see the importance of ClickCoordinates. Based on the type 
of event we're going to be working with, it's going to need to store different data 
in the GUi_Event structure. By using a union inside this structure, we're going to 
nnot have 
s of other 

classes. It is because of this restriction that we are forced to define our own struct 
that holds two floats and represents a point. 



The boost library could potentially be useful in a situation like 
this as it provides boost : : variant, which is a type-safe 
union container that doesn't have these limitations. It also has 
little or no overhead. 


which 
face the 
sked 

yourself by now why we're using const char* data types instead of std : : string, 
re will be 

incorporated into a union. Unfortunately, std : : string falls into the same trap as 
sf : : Vector2 f and cannot be used in a union without extra work. 
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The interface class 

a window 

that can be moved around and scrolled and has all of the same features and event 
hooks as a regular element. Efficiency is also a great concern, as dealing with lots of 
elements in a single window is a definite possibility. Those problems can be dealt 
with by carefully designing a way of drawing elements at the appropriate time. 

The way we want our interfaces to draw content is by using three separate textures 
for different purposes, as shown below: 



• The background layer is used for drawing backdrop elements 

• The content layer is where all of the elements of the interface are drawn 

• The controls layer hosts elements such as scrollbars that manipulate the 
content layer and don't need to be scrolled 

tention. As 

it happens, the std: : unordered_map structure serves this purpose well: 

using Elements = std :: unordered_map<std :: string, GUI_Element*> ; 

Next, a forward declaration of the owner class is needed to prevent cross-inclusion: 
class GUI_Manager; 

All of this brings us to the GUl_lnterf ace class: 

class GUI_Interf ace : public GUI_Element{ 
friend class GUI_Element; 
friend class GUI_Manager ; 
public : 

private : 

void DefocusTextf ields ( ) ; 

Elements m_elements; 
sf::Vector2f m_elementPadding ; 
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GUI_Interf ace* m_parent ; 

GUI_Manager* m_guiManager ; 

sf : : RenderTexture* m_backdropTexture ; 
sf::Sprite m_backdrop; 

/ / Movement . 

sf : : RectangleShape m_titleBar; 
sf::Vector2f m_moveMouseLast ; 
bool m_showTitleBar ; 
bool m_movable; 
bool m_beingMoved; 
bool m_focused; 

// Variable size. 

void AdjustContentSize (const GUI_Element* l_reference= nullptr) ; 

void SetContentSize ( const sf : : Vector2f & l_vec) ; 

sf : : RenderTexture* m_contentTexture ; 

sf::Sprite m_content; 

sf::Vector2f m_contentSize ; 

int m_scrollHorizontal ; 

int m_scrollVertical ; 

bool m_contentRedraw; 

// Control layer. 

sf : : RenderTexture* m_controlTexture ; 
sf::Sprite m_control; 
bool m_controlRedraw; 


} ; 



Note the declarations of friend classes. Both the GUI_Element 
and GUI_Manager need to have access to private and protected 
members of this class. 


es for the 

implementation section of this chapter. 

In addition to having an element container, an interface also defines the amount of 
f it has one, as 
rent layers. The 
understood 

unless we talk about implementation details, so let's get right to it! 
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Implementing the interface class 

A nice place to start, as always, is with the class constructor: 

GUI_Interf ace :: GUI_Interf ace (const std :: strings l_name, 

GUI_Manager* l_guiManager ) 

: GUI_Element ( l_name , GUI_ElementType :: Window, this), 
m_parent (nullptr) , m_guiManager ( l_guiManager ) , m_movable ( false ) , 
m_beingMoved (false) , m_showTitleBar (false) , m_focused (false) , 
m_scrollHorizontal ( 0 ) , m_scrollVertical ( 0 ) , m_contentRedraw ( true ) , 
m_controlRedraw (true) 

{ 

m_backdropTexture = new sf :: RenderTexture () ; 
m_contentTexture = new sf :: RenderTexture () ; 
m_controlTexture = new sf :: RenderTexture () ; 

} 

Quite a lot of data members are initialized through the initializer list here. Firstly, the 
parent class GUl_Element needs to know the name, type, and owner of the interface. 
One of the GUl_lnterf ace arguments is its name, which gets passed to the GUI_ 
Element constructor. The type is, of course, set to Window, and the this keyword 
the interface 

is initialized to its default value nullptr and a pointer to the GUl_Manager class is 
stored inside the m_guiManager data member. 

n which three 

sf : : RenderTexture objects are allocated dynamically. These are the textures that 
erface. 

Next, let's take a look at freeing up all of these resources in the destructor: 

GUI_Interf ace : : ~GUI_Interf ace ( ) { 
delete m_backdropTexture ; 
delete m_contentTexture ; 
delete m_controlTexture ; 
for (auto &itr : m_elements) { 
delete itr. second; 

} 

} 

very single 
uction. 

Afterwards, the element container is cleared. 
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take a look: 

void GUI_Interf ace :: SetPosition (const sf : : Vector2f& l_pos){ 
GUI_Element: : SetPosition (l_pos) ; 
m_backdrop . setPosition (l_pos) ; 
m_content . SetPosition (l_pos) ; 
m_control . setPosition (l__pos) ; 
m_titleBar .setPosition (m_position . x, 

m_position.y - m_titleBar . getSize ( ) . y) ; 
m_visual . m_text . setPosition (m_titleBar . getPosition ( ) 

+ m_style [m_state] . m_textPadding) ; 

} 

Firstly, the SetPosition method of the parent class is invoked in order to adjust the 
actual position. There is no need to fix what isn't broken. Next, the three sprites that 
ns adjusted 
position is set 

to be right above the interface, while the text of the visual component is used as a 
title and adjusted to take the same position as the title bar background, except with 
text padding included. 

in which 

elements can be added to them: 

bool GUI_Interf ace : :AddElement (const GUI_ElementType& l_type, 
const std : : strings l_name) 

{ 

if (m_elements . f ind ( l_name) != m_elements . end ()){ return false;} 
GUI_Element* element = nullptr; 

element = m_guiManager- >CreateElement ( l_type , this) ; 

if (!element){ return false; } 

element - >SetName (l_name) ; 

element ->SetOwner (this) ; 

m_elements . emplace ( l_name , element) ; 

m_contentRedraw = true; 

m_controlRedraw = true; 

return true; 

} 

It is important to avoid name clashes so check the name provided as the second 
f none 

are found, a CreateElement method of the GUI_Manager class is used to create 
an element of the relevant type on the heap and return its memory address. After 
properties 

are set before it gets inserted into the element container. The interface then sets two 
flags to re-draw the content and control layers. 
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Any interface needs to have a way to provide access to its elements. That's where the 
GetElement method comes in: 

GUI_Element* GUI_Interf ace : :GetElement (const std :: strings l_name) 
const { 

auto itr = m_elements . f ind (l_name) ; 

return(itr != m_elements . end ( ) ? itr->second : nullptr); 

} 

It simply locates the element in the std : : unordered map using its find method and 
returns it. If the element isn't found, nullptr is returned instead. Easy. 

Next, we need to have a way to remove elements from interfaces: 

bool GUI_Interf ace :: RemoveElement (const std::string& l_name) { 
auto itr = m_elements . f ind (l_name) ; 
if (itr == m_elements . end ( ) ) { return false; } 
delete itr->second; 
m_elements . erase ( itr) ; 
m_contentRedraw = true; 
m_controlRedraw = true; 

AdjustContentSize ( ) ; 
return true; 

} 

Following the same example as the GetElement method, the element is first located 
inside the container. The dynamic memory is then de-allocated by using the delete 
face is 

marked to re-draw its content and control layers and the AdjustContentSize 
method is invoked to re-size the content texture, if needed. 

We need to override the original is inside method because interfaces occupy 
additional space due to their title bars, as shown here: 

bool GUI_Interf ace Islnside (const sf : : Vector2f & l_point) const{ 
if (GUI_Element :: Islnside (l_point) ) { return true; } 
return m_titleBar . getGlobalBounds ( ) . contains (l_point) ; 

} 

The parent class method is invoked first to determine if l point is inside the space 
an interface is occupying. If not, the result of the title bar bounding box’s contains 
method is returned to determine if l_point is inside that. 
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Next is shown the de-serialization portion of the code: 

void GUI_Interf ace : : Readln ( std : : stringstream& l_stream) { 
std: : string movableState; 
std::string titleShow; 
std::string title; 

l_stream >> m_e lement Padding . x >> m_elementPadding . y 
>> movableState >> titleShow; 

Utils: : ReadQuotedString (l_stream, title) ; 
m_visual ,m_text . setstring (title) ; 

if (movableState == "Movable")! m_movable = true; } 
if (titleShow == "Title") { m_showTitleBar = true; } 

} 

All interfaces first read in the element padding x and y values, as well as the state 
and title parameters. It then uses the ReadQuotedText utility function which we 
defitrings read 

in, it then sets the m_movable and m_showTitleBar flags to reflect those values. 

Now comes the fun part. Let's define what happens when an interface is clicked: 

void GUI_Interf ace : :OnClick (const sf : : Vector2f& l_mousePos) { 
DefocusTextf ields () ; 

if (m_titleBar . getGlobalBounds (). contains ( l_mousePos) && 
m_movable && m_showTitleBar ) 

{ 

m__beingMoved = true; 

} else { 

GUI_Event event ; 

event. m_type = GUI_EventType :: Click; 
event . minterf ace = in name . c_str ( ) ; 
event . m_e lement = " " ; 

event . mclickCoords . x = l_mousePos.x; 
event . m_clickCoords .y = l_mousePos .y; 
m_guiManager- >AddEvent (event) ; 
for (auto &itr : m_elements) { 

if (! itr . second- >lslnside ( l_mousePos) ) { continue; } 
itr . second- >OnClick (l_mousePos) ; 
event . m_e lement = itr . second- >m_name . c_str () ; 
m_guiManager- >AddEvent (event) ; 

} 

SetState (GUI_ElementState : : Clicked) ; 

} 

} 
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oving focus 

from all of the Textf ield GUI elements. This will be covered in more depth later, 
f the mouse 

position is in the title bar area and the interface itself is movable, we set the 
m_beingMoved flag to true to indicate interface dragging. 

In a case of it just being a regular click anywhere else within the interface boundaries, 
we first set up an event that is going to be dispatched, indicating that a click has 
happened. The type is set to Click, the interface name is copied as a c string, and the 
mouse coordinates are also set up. The AddEvent method of the GUl_Manager class is 
invoked with our newly created event as an argument. This first event indicates that 
a click happened within the interface itself and not in any particular element. 

nt in the 

interface. Their Is Inside method is called to determine whether the click that 
took place was also within any of the elements. If so, the OnClick method of that 
gument. 

The same event that was set up before the loop is then slightly modified to contain 
the name of the element and is fired again, indicating that the click also affects it. 

The interface's state is then changed to clicked. The result of this is quite appealing 
to the eye: 



Next, let's take a look at the opposite side of clicking — the OnRelease method: 

void GUI_Interf ace :: OnRelease () { 

GUI_Event event ; 

event. m_type = GUI_EventType :: Release ; 
event . m_interf ace = m_name . c_str ( ) ; 
event . m_element = " " ; 
m_guiManager- >AddEvent (event) ; 
for (auto &itr : m_elements) { 

if ( itr . second- >GetState ( ) != GUI_ElementState :: Clicked) 

{ 
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continue ; 

} 

itr . second- >OnRelease ( ) ; 

event . me lement = itr . second- >m_name . c_str () ; 
m_guiManager- >AddEvent (event) ; 

} 

SetState (GUI_ElementState : : Neutral) ; 

} 

Just like before, an event is set up and fired, indicating that a release happened 
within this specific interface. Every element is then iterated over and their states 
are checked. If the element is in a Clicked state, its OnRelease method is called 
and another event is fired, indicating the release of the left mouse button within 
that element. The state of the interface is then set to Neutral. 

An interface also needs to deal with text being entered: 

void GUI_Interf ace : : OnTextEntered (const char& l_char) { 
for (auto &itr : m_elements) { 

if ( itr . second- >GetType ( ) != GUI_ElementType :: Textf ield) { 

continue ; 

} 

if ( itr . second- >GetState ( ) != GUI_ElementState :: Clicked) { 

continue ; 

} 

if ( l_char == 8 ) { 

// Backspace. 

const auto& text = itr . second- >GetText () ; 

itr . second- >SetText (text . substr (0, text . length ( ) -1) ) ; 

return; 

} 

if (l_char <32 | | l_char > 126) { return; } 
std: : string text = itr . second- >GetText () ; 
text .push_back (l_char) ; 
itr . second- >SetText ( text ) ; 
return; 

} 

} 


This method is going to be invoked whenever an SFML event 
sf : : Event : : TextEntered is received by our window. Each element is iterated 
over until we find one that is of the type Textf ield and is currently in a Clicked 
racter of 

our element's text attribute trimmed. Note that we're returning from the method in 
multiple places in order to avoid several Textf ield elements receiving the same 
text that is being entered. 
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been 

received. Any characters below ID 32 or above 12 6 are reserved for other purposes 
d in, we want 

to update our text attribute by adding that character to it. 

The full table of ASCII characters can be found here: http : // www . 
asciitable . com/ 

Since we're on the subject of handling text field elements, let's take a look at a 
method that we used before when handling a Click event: 

void GUI_Interf ace : : Def ocusTextf ields ( ) { 

GUI_Event event ; 

event. m_type = GUI_EventType :: Release ; 
event . m_interf ace = m_name . c_str ( ) ; 
event . m_element = " " ; 
for (auto &itr : m_elements) { 

if ( itr . second- >GetType ( ) != GUI_ElementType :: Textf ield) { 

continue ; 

} 

itr . second- >SetState (GUI_ElementState : : Neutral) ; 
event.m_eleraent = itr . second- >m_name . c_str () ; 
m_guiManager- >AddEvent (event) ; 

} 

} 

When handling text fields, it's important to bear in mind that they lose focus every 
xt entered 

across multiple textboxes, and that is no good. Making a text field lose focus is as 
simple as constructing a Release event and sending it to every Textf ield element 
that an interface possesses. 

The next two methods are grouped together due to their similarities: 

void GUI_Interf ace :: OnHover ( const sf : : Vector2f & l_mousePos) { 
GUI_Event event ; 

event. m_type = GUI_EventType :: Hover ; 
event . m_interf ace = m_name . c_str ( ) ; 
event . m_element = " " ; 

event . m_clickCoords . x = l_mousePos.x; 
event .m_clickCoords .y = l_mousePos . y ; 
m_guiManager- >AddEvent (event) ; 
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SetState (GUI_ElementState : : Focused) ; 

} 

void GUI_Interf ace : : OnLeave ( ) { 

GUI_Event event ; 

event . m_type = GUI_EventType : : Leave ; 
event . m_interf ace = m_name . c_str ( ) ; 
event . m_element = " " ; 
m_guiManager- >AddEvent (event) ; 

SetState (GUI_ElementState : : Neutral) ; 

} 

An event is constructed including the mouse coordinates when the mouse hovers 
a as in the 

OnLeave method. OnHover and OnLeave are only called once per event as they 
do not deal with elements. That job is left to the Update method: 

void GUI_Interf ace :: Update ( float l_dT) { 
sf::Vector2f mousePos = sf : : Vector2f ( 

m_guiManager- >GetContext () - >m_eventManager- >GetMousePos ( 
m_guiManager- >GetContext ( ) - >m_wind- >GetRenderWindow ( ) ) ) ; 

if (m_beingMoved && m_moveMouseLast != mousePos) { 

sf::Vector2f difference = mousePos - m_moveMouseLast ; 
rrpjnoveMouseLast = mousePos; 

sf::Vector2f newPosition = m_position + difference; 
SetPosition (newPosition) ; 

} 


} 

After the mouse position is obtained, the m_beingMoved flag is checked to determine 
whether or not an interface is currently being dragged. If it is, and the saved position 
difference is 

calculated and the interface's location is adjusted based on it. With that out of the 
way, let's take a look at the omitted chunk of code: 

for (auto &itr : m_elements) { 
if ( itr . second- >NeedsRedraw ( ) ) { 

if ( itr . second- >IsControl ()) { m_controlRedraw = true; } 
else { m_contentRedraw = true; } 

} 

if (! itr . second- >IsActive ()) { continue; } 
itr . second- >Update ( l_dT) ; 
if (m_beingMoved) { continue; } 
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GUI_Event event ; 

event . m_interf ace = m_name . c_str ( ) ; 

event . m_element = itr . second- >m_name . c_str () ; 

event . m_clickCoords . x = mousePos. x; 

event . m_clickCoords . y = mousePos. y; 

if (Islnside (mousePos) && itr . second- >lslnside (mousePos ) 

Sc& ! m_titleBar . getGlobalBounds ( ) . contains (mousePos) ) 

{ 

if ( itr . second- >GetState ( ) != GUI_ElementState :: Neutral ) { 

continue ; 

} 

itr . second- >OnHover (mousePos) ; 
event. m_type = GUI_EventType :: Hover ; 

} else if ( itr . second- >GetState ( ) == GUI_ElementState :: Focused) { 
itr . second- >OnLeave ( ) ; 
event. m_type = GUI_EventType :: Leave ; 

} 

m_guiManager- >AddEvent (event) ; 

} 

We begin by checking if the current element needs to be re-drawn. The relevant flag 
for re-drawing the entire interface is set to true if one is encountered, while taking 
into account whether it's a control element or not. 

eked. If an 

element is active, it gets updated. If the interface currently isn't being moved and the 
mouse is inside both the interface and the element, but not the title bar, the element's 
current state is checked. A Hover event needs to be dispatched and the OnHover 
method needs to be called if the element's current state is Neutral. However, if the 
mouse is not over the element, or the current interface's state is Focused, a Leave 
event is created and submitted, along with the OnLeave method being invoked. 

rface: 

void GUI_Interf ace :: Draw ( sf :: RenderTarget* l_target) { 
l_target- >draw (m_backdrop) ; 
l_target- >draw (m_content ) ; 
l_target- >draw (m_control ) ; 

if ( ! m_showTitleBar ) { return; } 
l_target- >draw (m_titleBar) ; 
l_target- >draw (m_visual . m_text) ; 

} 
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der textures. 

In order to draw an interface successfully, the sprites for the background, content, 
and control layers have to be drawn in that specific order. If the m_showTitleBar 
flag is set to true, the title background must also be drawn along with the text. 

Whereas the Update method does most of the work, moving interfaces requires a 
bit more preparation. Let's begin by defining two helper methods for movement, 
starting with the one used to initiate the process: 

void GUI_Interf ace : : BeginMoving ( ) { 

if ( ! m_showTitleBar | | !m_movable) { return; } 
m_beingMoved = true; 

SharedContext* context = m_guiManager- >GetContext ( ) ; 
m_raoveMouseLast = sf : ;Vector2f (context- >m_eventManager- > 
GetMousePos (context - >m_wind- >GetRenderWindow ( ) ) ) ; 

} 

If the conditions to move an interface are met, this method is invoked in order 
to save the mouse position at the point where dragging began. 

We also have a simple line of code to stop interface movement: 

void GUI_Interf ace : ; StopMoving ( ) { m_beingMoved = false; } 

to define 

their own way of obtaining their global position, as shown here: 

sf::Vector2f GUI_Interf ace : : GetGlobalPosition ( ) const{ 
sf::Vector2f pos = m_position; 

GUI_Interf ace* i = m_parent ; 
while (i) { 

pos += i- >GetPosition ( ) ; 
i = i - >m_parent ; 

} 

return pos; 

} 

n of parent 

interfaces and sum all of their positions. A while loop serves as a nice way of 
doing this; the final position is returned when it concludes. 

t types. Let's 
take a look: 

void GUI_Interf ace : : ApplyStyle ( ) { 

GUI_Element ; : ApplyStyle ( ) ; // Call base method. 
m_visual . m_backgroundSolid . setPosition ( 0 . f , 0 . f ) ; 
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m_visual . m_backgroundImage . setPosition ( 0 . f , 0 . f ) ; 
m_titleBar .setSize(sf: : Vector2f ( 

m_style [m_state] . m_size . x, 16 . f ) ) ; 
m_titleBar .setPosition (m_position . x, 

m_position.y - m_titleBar . getSize ( ) . y) ; 
m_titleBar . setFillColor (m_style [m_state] . m_elementColor ) ; 
m_visual . m_text . setPosition (m_titleBar . getPosition ( ) 

+ m_style [m_state] . m_textPadding) ; 
m_visual . m_glyph . setPosition (m_titleBar . getPosition ( ) 

+ m_style [m_state] . m_glyphPadding) ; 

} 

The ApplyStyle method is invoked first because the parent class does a great job of 
nts then 
nterfaces 
he position 

of the interface, the positions of these elements will not change. 

Next, the title bar background is set up to match the size of the interface on the x 
axis and should have a height of 16 pixels on the y axis. This hardcoded value can be 
tweaked at any time. Its position is then set to be right above the interface. The fill 
color of the title background is defined by the element color property of its style. 

The last four lines set up the position of the title bar text and glyph. The position of 
the title bar background is summed together with the relevant padding to obtain the 
final position of these two attributes. 

xtures, starting 

with the background layer: 

void GUI_Interf ace :: Redraw () { 

if (m__backdropTexture->getSize ( ) . x ! =m_style [m_state] ,m_size.x | 
m_backdropTexture- >getSize ( ) .y != m_style [m_state] .m_size.y) 

{ 

m_backdropTexture->create (m_style [m_state] .m_size .x, 
m_style [m_state] .m_size.y) ; 

} 

m_backdropTexture- >clear ( sf :: Color ( 0 , 0, 0, 0) ) ; 

ApplyStyle ( ) ; 

m_backdropTexture- >draw (m_visual . m_backgroundSolid) ; 

if (m__style [m_state] . m backgroundlmage != ""){ 

m_backdropTexture->draw (m_visual .m_backgroundImage) ; 

} 
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m_backdropTexture- >display ( ) ; 

m_backdrop . setTexture (m_backdropTexture- >getTexture ( ) ) ; 
m_backdrop . setTextureRect ( sf : : IntRect ( 0 , 0 , 

m_style [m_state] .ra_size.x, m_style [m_state] .m_size.y) ) ; 

SetRedraw ( false) ; 

} 

Firstly, a check is made in order to be sure that the background texture is the 
reated with 
the correct size. 

The next line is extremely important for good looking results. At first glance, it 
er, you will 

the alpha 

channel, or the transparency value for the color. The texture cleared to black appears 
as a large black square, and that's not what we want. Instead, we want it to be 
value 

of 0 will do. 

Next, the ApplyStyle method is invoked in order to adjust the visual parts of the 
round image 

are then drawn onto the background texture. The texture's display method must be 
der window. 

Lastly, the background sprite is bound to the background texture and its visible area 
is cropped to the interface size in order to prevent overflow. The redraw flag is set 
to false to indicate that this process is complete. 

A very similar process also needs to occur for the content layer: 

void GUI_Interf ace : : RedrawContent () { 

if (m_contentTexture- >getSize ( ) .x != m_contentSize . x | i 
m_contentTexture- >getSize ( ) . y != m_contentSize . y) 

{ 

m_contentTexture- >create (m_contentSize . x, m_contentSize . y) ; 

} 


m_contentTexture- >clear (sf :: Color ( 0 , 0, 0, 0) ) ; 

for (auto &itr : m_elements) { 

GUI_Element* element = itr. second; 

if (! element- >IsActive ( ) | | element->IsControl ( ) ) { continue; } 

element - >ApplyStyle ( ) ; 

element - >Draw (m_contentTexture) ; 

element - >SetRedraw (false) ; 
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} 

m_contentTexture- >display ( ) ; 

m_content . setTexture (m_contentTexture- >getTexture ( ) ) ; 

m_content . setTextureRect (sf : : IntRect ( 
m_scrollHorizontal , m_scrollVertical , 

m_style [m_state] .m_size.x, m_style [m_state] .m_size.y)) ; 
m_contentRedraw = false; 

} 

The content texture is checked for dimensions. The only difference here is that we're 
keeping a manual track of its size in the m_contentSize float vector, which will be 
covered later. 

the interface 
conditions are 
satisfiexture, 

which gets passed in as the argument of the Draw method. Its re-draw flag is then 
set to false. 

After displaying the texture and binding it to a relevant sprite, it too gets cropped, 
except that, this time, we use the m_scrollHorizontal and m_scrollVertical data 
members as the first two arguments in order to account for scrolling. Consider the 
following illustration: 
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tent 

texture. The m_contentRedraw flag then gets set to false to signify that the re-draw 
process has concluded. It leaves us with a result that looks like this: 



The final layer of the interface follows an almost identical path: 

void GUI_Interf ace : : RedrawControls ( ) { 

if ( m_cont rolTexture - >getSize ( ) . x ! =m_style [m_state] .m_size.x | 
m_controlTexture- >getSize ( ) .y != m_style [m_state] . m_size . y) 

{ 

m_controlTexture- >create (m_style [m_state] . m_size . x, 
m_style [m_state] .m_size.y) ; 

} 

m_controlTexture- >clear (sf :: Color ( 0 , 0, 0, 0) ) ; 

for (auto &itr : m_elements) { 

GUI_Element* element = itr. second; 

if (! element- >IsActive ( ) | [ ! element- >IsControl ()) { continue; } 

element- >ApplyStyle () ; 

element ->Draw (m_controlTexture) ; 

element - >SetRedraw (false) ; 

} 

m_controlTexture- >display ( ) ; 

m_control . setTexture (m_controlTexture- >getTexture ( ) ) ; 
m_control . setTextureRect (sf : : IntRect ( 0 , 0 , 

m_style [m_state] .m_size.x, m_style [m_state] .m_size.y)) ; 
m_controlRedraw = false; 

} 

of the current 

style, just like the background layer. Only the control elements are drawn this time. 
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k at how it 
is done: 

void GUI_Interf ace : : UpdateScrollHorizontal ( 
unsigned int l_percent) 

{ 

if (l_percent > 100) { return; } 

m_scrollHorizontal = ( (m_contentSize . x - GetSizeO .x) / 100) * 
l_percent ; 

sf::IntRect rect = m_content . getTextureRect () ; 
m_content . setTextureRect (sf : : IntRect ( 

m_scrollHorizontal , m_scrollVertical , rect . width, rect . height ) ) ; 

} 

void GUI_Interf ace :: UpdateScrollVertical (unsigned int l_percent) { 
if (l_percent > 100) { return; } 

m__scrollVertical = ( (m_contentSize . y - GetSizeO .y) / 100) * 
l_percent ; 

sf:: IntRect rect = m_content . getTextureRect () ; 
m_content . setTextureRect ( sf : : IntRect ( 

m_scrollHorizontal , m_scrollVertical , rect . width, rect . height ) ) ; 

} 

value 
nt of pixels 

an interface should be offset by is calculated by first dividing the difference of its 
y a hundred, and 

multiplying the result by the percentage argument. The texture rectangle is then 
obtained to maintain the proper width and height of the content area, which is then 
re-set with the scroll values as the first two arguments. This effectively simulates 
the scroll sensation of an interface. 

may alter 

its size. Here's a method to solve those problems: 

void GUI_Interf ace : : AdjustContentSize ( 
const GUI_Element* preference) 

{ 

if (l_ref erence) { 

sf::Vector2f bottomRight = 

l_reference->GetPosition ( ) + preference- >GetSize ( ) ; 
if (bottomRight . x > m_contentSize . x) { 
m__contentSize . x = bottomRight . x; 
m_controlRedraw = true; 

} 
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if (bottomRight . y > m_contentSize .y) { 
m_contentSize . y = bottomRight . y; 
m_controlRedraw = true; 

} 

return; 

} 


sf::Vector2f farthest = GetSizeO; 

for (auto &itr : m_elements) { 

GUI_Element* element = itr. second; 

if (! element- >IsActive ( ) | | element->IsControl ( ) ) { continue; } 

sf::Vector2f bottomRight = 

element - >GetPosition ( ) + element- >GetSize () ; 
if (bottomRight . x > farthest.x){ 
farthest. x = bottomRight .x; 
m_controlRedraw = true; 

} 

if (bottomRight ,y > farthest.y){ 
farthest. y = bottomRight . y; 
m_controlRedraw = true; 

} 

} 

SetContentSize ( farthest ) ; 

} 

Before examining it in depth, I can show you that, inside the class definition, this 
method looks like this: 

void AdjustContentSize (const GUI_Element* preference = nullptr); 

Its only argument has a default value of nullptr, which enables the method to 
detect size changes with or without a reference element. 

If an element is provided as an argument, which usually happens when one is added 
g its position 

and size. If these coordinates are somewhere outside of the content size boundaries, 
the content size is adjusted to be larger and the control redraw flag is set to true 
hod then 

returns in order to prevent the rest of the logic from being executed. 
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Without a reference element, a float vector is set up to keep track of the farthest point 
within the interface texture, the original value of which is the interface size. Every 
active non-control element is then iterated over and checked to see if it exceeds the 
furthest point in the texture, which simply gets overwritten on a relevant axis. If 
an element is found that pokes outside of these boundaries, its bottom-right corner 
position is stored and the control layer is marked for re-drawing. The content size itself 
is set to the farthest corner of the interface after all of the elements have been checked. 

This final code snippet concludes the interface class. 

Summary 

ve written 
d managed, 
plementing 

a fully functional GUI system but it only represents all the pieces being laid out. 

So far, we have covered the basic design of GUI elements and windows, as well as 
implementing quite a few useful features that different types of elements can use. 
While that is a lot of code, we're not quite done yet. In the next chapter, we will be 
tual GUI 

elements. See you there! 


[ 315 ] 





Don't Touch the Red Button! 
- Implementing the GUI 


We covered the fundamentals and created the building blocks necessary for graphical 
user interface assembly in the course of the last chapter. Although that might seem 
like lots of code, a lot more goes into making it tick. Proper management of interfaces, 
good support from the rest of the code base, and user-friendly semantics of the GUI 
system itself are all paramount. Let's finish our goal set in Chapter 10, Can I Click Tins? 
- GUI Fundamentals, and finally provide our users with a means of interfacing. 

In this chapter, we will cover the following topics: 

• Management of interfaces and their events 

• Expansion of the event manager class for additional GUI support 

• Creation of our first element type 

• Integration and use of our GUI system 

With all the pieces in place, let's bring our interfaces to life! 


The GUI manager 

The puppet master in the background, in charge of the entire show in this case, has 
to be the GUi_Manager class. It is responsible for storing all the interfaces in the 
ing originates 

from this class and is passed down the ownership tree. Let's begin by getting some 
type definitions out of the way: 

using GUI_Interf aces = std :: unordered_map<std :: string, 
GUI_Interface*> ; 

using GUI_Container = std : : unordered_map<StateType , 
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GUI_Interfaces> ; 

using GUI_Events = std : : unordered_map<StateType , 
std: : vector<GUI_Event >> ; 

using GUI_Factory = std: : unordered_map<GUI_ElementType , 
std : : function<GUI_Element* (GUI_Interf ace* ) >> ; 
using GUI_ElemTypes = std :: unordered_map<std :: string, 

GUI_ElementType> ; 

We will use the std : : unordered_map data structure that indexes them by name to 
grouped by 

game states, which is what the next type definition is for. Similarly, GUI events need 
to be indexed by their relevant game state. The events themselves are stored in a 
std: :vector. 

on, much like 

we did before, a factory type definition is created. The main difference here is that 
the lambda functions we'll be storing need to take in a pointer to the owner interface 
in order to be constructed correctly. 

Lastly, we're going to be mapping element type strings to actual enumeration values 
for the same. Once again, the std: : unordered_map type comes to the rescue. 

Now, here is the class definition itself: 

struct SharedContext ; // Forward declaration, 
class GUI_Manager{ 

friend class GUI_Interf ace ; 
public : 

GUI_Manager (EventManager* l_evMgr, SharedContext* l_context) ; 
~GUI_Manager ( ) ; 

template<class T> 

void RegisterElement (const GUI_ElementType& l_id) { 

m__f actory [l_id] = [] (GUI_Interf ace* l_owner) -> GUI_Element* 

{ return new T ( " " , l_owner ) ; }; 

} 

private : 

GUI_Element* CreateElement (const GUI_ElementType& l_id, 

GUI_Interf ace* l_owner) ; 

GUI_ElementType StringToType (const std : : strings l_string) ; 
bool LoadStyle (const std :: strings l_file, 

GUI_Element* l_element) ; 

GUI_Container m_interf aces ; 

GUI_Events m_events; 
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SharedContext* m_context; 

StateType m_currentState ; 

GUI_Factory m_factory; 

GUI_ElemTypes m_elemTypes; 

}; 

Right off the bat, we can tell that the factory method for elements is going to be used 
due to the presence of a RegisterElement method. It stores a lambda function with 
an owner interface pointer as its sole argument, which returns a GUi_Element type 
with a blank name, constructed from a given type denoted by the l_id argument. 

Its private method friend, CreateElement, will use the stored lambda functions 
and return pointers to newly created memory. 

One last thing to note before diving into the implementation of this class is the 
existence of a Loadstyle method that takes in a GUl_Element type. The manager 
class is responsible for de-serializing style files and properly setting up elements 
based on them to avoid cluttering up the element and interface classes. 

Implementing the GUI manager 

g our GUI 

manager. The constructor of the GUl_Manager class is defined like this: 

GUI_Manager: : GUI_Manager (EventManager* l_evMgr, 

SharedContext* l_shared) : m_eventMgr ( l_evMgr ) , 
m_context (l_shared) , m_currentState (StateType (0) ) 

{ 

RegisterElement<GUI_Label> (GUI_ElementType : :Label) ; 
RegisterElement<GUI_Scrollbar> (GUI_ElementType : : Scrollbar) ; 
RegisterElement<GUI_Textf ield> (GUI_ElementType : :Textfield) ; 
m_elemTypes . emplace ( "Label " , GUI_ElementType : : Label) ; 
m_elemTypes . emplace ( "Button" , GUI_ElementType : : Button) ; 
m_elemTypes . emplace ( "Scrollbar" , GUI_ElementType : : Scrollbar) ; 
m_elemTypes . emplace ( "TextField" , GUI_ElementType : :Textfield) ; 
m_elemTypes . emplace (" Interface" , GUI_ElementType : :Window) ; 

m_eventMgr- >AddCallback (StateType ( 0 ) , 

"Mouse_Lef t " , &GUI_Manager :: Handled ick, this); 
m_eventMgr- >AddCallback (StateType ( 0 ) , 

"Mouse_Lef t_Release " , &GUI_Manager : : HandleRelease , this); 
m_eventMgr- >AddCallback (StateType ( 0 ) , 

"Text_Entered" , &GUI_Manager : : HandleTextEntered, this); 

} 
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as 

arguments and sets them up through the initializer list, along with a default value 
for the current state. Inside the body, we can see that this class first registers three 
element types that we're going to be working with. It also populates the element type 
gisters three 
one for text 

being entered. Note that these callbacks are registered to be called regardless of the 
state the application is in. 


GUI_Manager : : ~GUI_Manager ( ) { 

m_eventMgr- >RemoveCallback (StateType ( 0 ) , 
m_eventMgr- >RemoveCallback (StateType ( 0 ) , 
m_eventMgr- >RemoveCallback (StateType ( 0 ) , 


"Mouse_Lef t " ) ; 
"Mouse_Lef t_Release " ) ; 
"Text_Entered" ) ; 


for (auto &itr : m_interf aces ) { 
for (auto &itr2 : itr. second) { 
delete itr2 . second; 

} 

} 

} 

r and iterates 
cated 

memory. The interface and event containers are then cleared. 

Let's take a look at how an interface is added to the GUI manager: 

bool GUI_Manager : :AddInterf ace (const StateType& l_state, 
const std : : strings l_name) 

{ 

auto s = m_interf aces . emplace ( l_state , GUI_Interf aces ()). first ; 
GUI_Interf ace* temp = new GUI_Interf ace ( l_name , this); 
if ( s - >second . emplace (l_name , temp) . second) { return true; } 
delete temp; 
return false; 

} 

is made 

when a valid application state and an unused interface name is provided. Any issues 
when inserting are caught by the return value of the emplace method, which gets 
stored in the i variable. If it fails, the memory is de-allocated and false is returned 
to signify failure. Otherwise, true is returned. 
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Obtaining an interface is as simple as it gets: 

GUI_Interf ace* GUI_Manager : : Getlnterf ace (const StateType& l_state, 
const std: : strings l_name) 

{ 

auto s = m_interfaces . f ind (l_state) ; 

if (s == m_interf aces . end ()) { return nullptr; } 

auto i = s- >second . f ind ( l_name ) ; 

return (i != s- >second . end ( ) ? i->second : nullptr); 

} 

ame provided 

is also located, it gets returned. Failure to find either a valid state or the correct 
interface is represented by a return value of nullptr. 


bool GUI_Manager :: Removelnterf ace (const StateTypek l_state, 
const std::string& l_name) 

{ 

auto s = m_interfaces . f ind (l_state) ; 

if (s == m_interf aces . end ()) { return false; } 

auto i = s- >second . f ind (l_name) ; 

if (i == s- >second . end ( ) ) { return false; } 

delete i->second; 

return s- >second . erase ( l_name) ; 

} 



Note that the delete keyword appears if both the state and the interface 
are found. Sometimes, it's very easy to forget the de-allocation of no 
longer used memory on the heap, which results in memory leaks. 


te, the 

following method is necessary: 


void GUI_Manager :: SetCurrentState (const StateTypek l_state) { 
if (m_currentState == l_state) { return; } 

HandleRelease (nullptr) ; 
nypurrentState = l_state; 


} 
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he 

HandleRelease method to prevent sticky interface and element states. If an element 
in the 

CLICKED state until it is hovered over unless HandleRelease is called, 
aces: 

void GUI_Manager : : HandleClick (EventDetails* l_details) { 
auto state = m_interf aces . find (m_currentState) ; 
if (state == m_interf aces . end ()) { return; } 
sf::Vector2i mousePos = m_eventMgr-> 

GetMousePos (m_context->m_wind->GetRenderWindow ( ) ) ; 
for (auto itr = state->second. rbegin ( ) ; 
itr != state- >second . rend () ; ++itr) 

{ 

if ( ! itr- >second- >lslnside ( sf : : Vector2f (mousePos) ) ) { continue ; } 
if ( ! itr- >second- >IsActive ( ) ) { return; } 
itr- >second- >OnClick (sf ; : Vector2f (mousePos) ) ; 
itr->second->Focus ( ) ; 

if ( itr- >second- >IsBeingMoved ( ) ) { itr- >second- >BeginMoving ( ) ; } 
return; 

} 

} 

This method, just like its HandleRelease brother, takes in a single argument of the 
type EventDetails. For now, simply ignore that as it does not affect GUI_Manager 
at all and will be dealt later in this chapter. 

Firstly, it obtains the current mouse position relative to the window. Next, an iterator 
to the interface container is obtained and checked for validity. Every interface 
that belongs to the current state is then iterated over in reverse order, which gives 
newly added interfaces priority. If it is active and the mouse position falls within its 
boundaries, its OnClick method is invoked, with the mouse position passed in as 
the argument. The interface's m_beingMoved flag is then checked because the click 
might've been within the boundaries of its title bar. If so, the BeginMoving method is 
called to complete the drag operation. At this point, we simply return from the method 
in order to prevent a left click from affecting more than one interface at a time. 

Handling the left mouse button release follows the same convention: 

void GUI_Manager : : HandleRelease (EventDetails* l_details) { 
auto state = m_interf aces . find (m_currentState) ; 
if (state == m_interf aces . end ()) { return; } 
for (auto &itr : state- >second) { 

GUI_Interf ace* i = itr. second; 
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if ( ! i- >IsActive ( ) ) { continue; } 
if (i->GetState ( ) == GUI_ElementState :: Clicked) 
{ 

i->OnRelease ( ) ; 

} 

if (i->IsBeingMoved ( ) ) { i->StopMoving ( ) ; } 

} 


The only difference here is that every interface which is in a clicked state has its 
OnRelease method called, as well as the StopMoving method if it is in a state of 
being dragged. 

Lastly, let's not forget about our text field elements as they need to be notified 
whenever some text is entered: 

void GUI_Manager : : HandleTextEntered (EventDetails* l_details) { 
auto state = m_interf aces . find (m_currentState) ; 
if (state == m_interf aces . end ()) { return; } 
for (auto &itr : state- >second) { 

if (! itr. second- >IsActive () ) { continue; } 

if (! itr . second- >IsFocused ()) { continue; } 

itr . second- >OnText Entered ( l_det ails - >m_t ext Entered) ; 

return; 

} 

} 

This is a quite simple snippet of code. Whenever text is entered, we attempt to find 
an active and focused element. Once we find one, its OnTextEntered method is 
invoked with the text information passed in as the argument. 

Adding GUI events is as simple as pushing them back onto a std : : vector data 
structure: 

void GUI_Manager : : AddEvent (GUI_Event l_event) { 
m_events [m_currentState] .push_back (l_event) ; 

} 

hem: 

bool GUI_Manager : : PollEvent (GUI_Event& l_event) { 

if (m_events [m_currentState] .empty()){ return false; } 
l_event = m_events [m_currentState] .back(); 
m_events [m_currentState] .pop_back() ; 
return true; 

} 
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ference to a 
GUI_Eventght 
y for it to be 
used in a while loop. 

Next, let's work on updating the interfaces: 

void GUI_Manager :: Update ( float l_dT) { 
sf::Vector2i mousePos = m_eventMgr-> 

GetMousePos (m_context->m_wind->GetRenderWindow ( ) ) ; 

auto state = m_interf aces . find (m_currentState) ; 
if (state == m_interf aces . end ()) { return; } 
for (auto itr = state->second. rbegin ( ) ; 
itr != state- >second . rend () ; ++itr) 

{ 

GUI_Interf ace* i = itr->second; 
if ( ! i- >IsActive ( ) ) { continue; } 
i->Update (l_dT) ; 

if ( i- >IsBeingMoved ( ) ) { continue; } 
if (i->lslnside (sf : :Vector2f (mousePos) ) ) 

{ 

if ( i - >GetState ( ) == GUI_ElementState :: Neutral ) { 
i->OnHover (sf : : Vector2f (mousePos) ) ; 

} 

return; 

} else if ( i- >GetState ( ) == GUI_ElementState :: Focused) { 
i - >OnLeave ( ) ; 

} 

} 

} 

gs to 

the current application state is iterated over. If the interface is currently active, it 
gets updated. The Hover and Leave events are only considered if the interface in 
elements 
inside interfaces. 

Now it's time to draw all of these interfaces onto the screen: 

void GUI_Manager :: Render ( sf RenderWindow* l_wind) { 
auto state = m_interf aces . find (m_currentState) ; 
if (state == m_interf aces . end ()) { return; } 
for (auto &itr : state- >second) { 

GUI_Interf ace* i = itr. second; 
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if ( ! i- >IsActive ( ) ) { continue; } 
if (i->NeedsRedraw ( ) ) { i->Redraw(); } 
if (i->NeedsContentRedraw ( ) ) { i->RedrawContent ( ) ; } 
if (i->NeedsControlRedraw ( ) ) { i->RedrawControls ( ) ; } 
i->Draw (l_wind) ; 



Once again, this method iterates over all interfaces that belong to the current 
application state. If they're active, each re-draw flag is checked and the appropriate 
re-draw methods are invoked. Finally, a pointer to the sf : : RenderWindow is passed 
into the Draw method of an interface so it can draw itself. 

because 

we're working with factory-produced element types: 

GUI_Element* GUI_Manager: ; CreateElement ( 

const GUI_ElementType& l_id, GUI_Interf ace* l_owner) 

{ 

if (l_id == GUI_ElementType :: Window) { 
return new GUI_Interf ace ( " " , this); 

} 

auto f = m_factory . f ind ( 1 id) ; 

return (f != m_f actory . end ( ) ? f - >second ( l_owner ) : nullptr) ; 

} 

If the provided element type is a window, a new interface is created, to which 
a pointer of GUl_Manager is passed as its second argument. In the case of any 
other element type being passed in, the factory container is searched and the 
stored lambda function is invoked with the l_owner argument passed in to it. 

Lastly, let's discuss the de-serialization of interfaces. A method is needed to load 
files formatted in this way: 

Interface name Style. style 0 0 Immovable NoTitle "Title" 

Element Label name 100 0 Style. style "Label text" 


Next, let's work on loading our interfaces from a file. We're not going to cover 
how the fi 

bool GUI_Manager :: Loadlnterf ace ( const StateTypek l_state, 
const std : : strings l_interface, const std::string& l_name) 

{ 

} 
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Let's start with creating an interface: 

if (key == " Interface ") { 
std::string style; 

keystream >> Interf aceName >> style; 
if ( ! Addlnterface (l_state, l_name) ) { 

std::cout << "Failed adding interface: " 

<< l_name << std::endl; 
return false; 

} 

GUI_Interf ace* i = Getlnterf ace ( l_state , l_name) ; 

keystream >> *i; 

if ( ILoadStyle (style, i) ) { 

std::cout << "Failed loading style file: " 

<< style << " for interface " << l_name << std::endl; 

} 

i - >Set Content Size ( i- >GetSize ( ) ) ; 

} else if ... 

As suggested by the file format, it first needs to read in its name and the name of the 
style fied out 
and the fi 

is obtained and its overloaded > > operator is used to read in additional information 
chapter. 

Next, an attempt is made to load the style file that was read in earlier by calling the 
LoadStylee is 

tyle. 

lar: 


} else if (key == "Element") { 
if ( Interf aceName == ""){ 

std::cout << "Error: 'Element 1 outside or before 
declaration of 'Interface'!" << std::endl; 
continue ; 

} 

std: : string type; 
std: : string name; 
sf::Vector2f position; 
std::string style; 

keystream >> type >> name >> position. x >> position. y >> style; 
GUI_ElementType eType = StringToType (type) ; 
if (eType == GUI_ElementType : :None) { 

std::cout << "Unknown element (' " << name 
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<< "') type: << type << << std::endl; 

continue ; 

} 

GUI_Interf ace* i = Getlnterf ace ( l_state , l_name) ; 
if (!i){ continue; } 

if ( ! i - >AddElement (eType , name) ) { continue; } 

GUI_Element* e = i - >GetElement (name) ; 
keystream >> *e; 
e->SetPosition (position) ; 
if ( ILoadStyle (style, e) ) { 

std::cout << "Failed loading style file: " << style 
<< " for element " << name << std: : endl ; 
continue ; 

} 

} 

rom the 

file. An element type is obtained after running the text that was read into the type 
variable through our helper method stringToType. An interface that the element 
ent to the 

Loadlnterf ace method. The AddElement method of the obtained interface is called 
in order to create the appropriate element type on the heap. If it's successful, the 
utilizing its 

overloaded >> operator. The Loadstyle method is invoked once again in order to 
read the style of an element from a file. Let's take a look at what this looks like: 

State Neutral 
Size 64 32 
TextColor 000 255 
TextSize 12 
Font Main 
TextPadding 0 0 
/ State 

State Hover 

TextColor 255 255 255 255 
/ State 

State Clicked 
TextColor 255 0 0 255 
/ State 
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gain, we're 

going to skip the code that reads the file as it is redundant. With that in mind, let's 
take a look: 

bool GUI_Manager :: LoadStyle ( const std::string& l_file, 

GUI_Element* l_element) 

{ 


std::string currentState; 
GUI_Style ParentStyle; 
GUI_Style TemporaryStyle; 


} 

Note the two GUl Style structures that are set up here: they keep track of the main 
style that serves as a parent and the temporary style that's currently being read in. 
Let's keep moving further down this method, inside the actual while loop: 

if (type == "State") { 

if (currentState != ""){ 

std::cout << "Error: 'State 1 keyword found 
inside another state!" << std::endl; 
continue ; 

} 

keystream >> currentState; 

} else if ... 

If a state keyword is encountered and currentState is not set up, the name of the 
state is read in. Otherwise, we print out an error message: 

} else if (type == "/State") { 
if (currentState == ""){ 

std::cout << "Error: '/State' keyword found 
prior to 'State'!" << std::endl; 
continue ; 

} 

GUI_ElementState state = GUI_ElementState :: Neutral ; 
if (currentState == "Hover" ){ state = GUI_ElementState :: Focused; } 
else if (currentState == "Clicked")! 
state = GUI_ElementState :: Clicked; 

} 


if (state == GUI_ElementState :: Neutral ) { 
ParentStyle = TemporaryStyle; 
l_element - >UpdateStyle ( 

GUI_ElementState : : Neutral, TemporaryStyle) ; 
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l_element->UpdateStyle ( 

GUI_ElementState : : Focused, TemporaryStyle) ; 
l_element->UpdateStyle ( 

GUI_ElementState : : Clicked, TemporaryStyle) ; 

} else { 

l_element- >UpdateStyle ( state , TemporaryStyle) ; 

} 

TemporaryStyle = ParentStyle; 
currentState = " " ; 

} else { ... 

When encountering a /state keyword, we can safely assume that the style currently 
being processed has ceased. The state is then determined based on the string that 
was read in denoting it. 

If the state is Neutral, we need to set it to be the parent style, which means that 
every unset property of the other styles will also be inherited from this one. The 
UpdateStyle method is then invoked for each of the three supported states in 
order to overwrite the default values. If it is anything other than Neutral, the 
UpdateStyle method is only invoked once for that state. The TemporaryStyle 
variable is then overwritten with ParentStyle to simulate inheritance. 

Finally, let's see how every different style feature is supported: 

} else { 

// Handling style information, 
if (currentState == ""){ 

std::cout << "Error: << type 

<< keyword found outside of a state!" << std::endl; 
continue ; 

} 

if (type == "Size"){ 

keystream >>TemporaryStyle . m_size . x >>TemporaryStyle . m_size . y ; 

} else if (type == "BgColor"){ 
int r, g, b, a = 0 ; 
keystream >> r >> g >> b >> a; 

TemporaryStyle . m_backgroundColor = sf : : Color (r , g, b , a) ; 

} else if (type == "Bglmage"){ 

keystream >> TemporaryStyle . m_backgroundImage ; 

} else if (type == "BglmageColor " ) { 
int r, g, b, a = 0 ; 
keystream >> r >> g >> b >> a; 

TemporaryStyle . m_backgroundImageColor = sf::Color(r, g, b, a); 

} else if (type == "TextColor " ) { 
int r, g, b, a = 0 ; 
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keystream >> r >> g >> b >> a; 

TemporaryStyle . m_textColor = sf::Color(r, g, b, a); 

} else if (type == "TextSize"){ 

keystream >> TemporaryStyle . m_textSize ; 

} else if (type == "TextOriginCenter" ) { 

TemporaryStyle . m_textCenterOrigin = true; 

} else if (type == "Font"){ 

keystream >> TemporaryStyle . m_textFont ; 

} else if (type == "TextPadding" ) { 

keystream >> TemporaryStyle . m_textPadding . x 
>> TemporaryStyle . m_t ext Padding . y ; 

} else if (type == "ElementColor" ) { 
int r, g, b, a = 0; 
keystream >> r >> g >> b >> a; 

TemporaryStyle . m_element Color = sf::Color(r, g, b, a); 

} else if (type == "Glyph") { 

keystream >> TemporaryStyle .m_glyph; 

} else if (type == "GlyphPadding" ) { 

Keystream >> TemporaryStyle . m_glyphPadding . x 
>> TemporaryStyle . m_glyphPadding . y ; 

} else { 

std::cout << "Error: style tag << type 
<< is unknown!" << std::endl; 

} 

} 

Every color value is first read in as four separate integers and then stored in a 
sf : : Color structure which gets assigned to the appropriate data member of the 
eption to 

this is the TextOriginCenter tag. It does not contain any additional information 
should 

always be centered. 


The label element 

A label element is the simplest GUI type yet. It supports all of the default stylistic 
value that 

can be loaded in or set at runtime. 

Let's take a look at its constructor and destructor: 

GUI_Label :: GUI_Label (const std : : string& l_name , 

GUI_Interf ace* l_owner) 

: GUI_Element (l_name , GUI_ElementType :: Label , l_owner) { } 
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This is nothing short of child's play in comparison to the code we've written before. Its 
name, type, and owner are set up in the initializer list and there's nothing else to it. 

11 the following 

line from an interface file: 

Element Label TestLabel 0 0 Default . style "Some text" 

Since the GUi_Manager class takes care of all of this information except the last part, 
the Readln method of this element might look like this: 

void GUI_Label :: Readln ( std :: stringstream& l_stream) { 
std: : string content ; 

Utils: : ReadQuotedString (l_stream, content) ; 
m_visual . m_text . setstring ( content ) ; 

} 

e, it's 

nothing more than simply adjusting the state of the label: 

void GUI_Label : :OnClick (const sf : : Vector2f& l_mousePos) { 

SetState (GUI_ElementState : : Clicked) ; 

} 

void GUI_Label : : OnRelease ( ) { 

SetState (GUI_ElementState : : Neutral) ; 

} 

void GUI_Label :: OnHover (const sf : : Vector2f& l_mousePos) { 

SetState (GUI_ElementState : : Focused) ; 

} 

void GUI_Label : :OnLeave () { 

SetState (GUI_ElementState : : Neutral) ; 

} 

The final bit of code is responsible for how this element is drawn: 

void GUI_Label : : Draw ( sf : : RenderTarget* l_target) { 
l_target- >draw (m_visual . m_backgroundSolid) ; 
if (m_style [m_state] .m_glyph != ""){ 
l_target- >draw (m_visual . m_glyph) ; 

} 

l_target- >draw (m_visual . m_text) ; 

} 

After the background rectangle is drawn, the glyph is checked to see whether it 
the last two 
visual attributes. 
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The text field element 

In order to implement a text field element successfully, we need to define how it 
responds to input correctly. Firstly, let's set up a new element type by creating the 
text field element class and implementing the constructor, as shown here: 

GUI_Textf ield :: GUI_Textf ield (const std::string& l_name , 

GUI_Interf ace* l_owner) 

: GUI_Element (l_name , GUI_ElementType : : Textf ield , l_owner) { } 
press that by 

providing a custom version of the Readln method: 

void GUI_Textf ield :: Readln ( std :: stringstream& l_stream) { 
std: : string content; 

Utils: : ReadQuotedString ( l_stream, content) ; 
m_visual . m_text . setstring ( content ) ; 

} 

As you probably know, text fields do not change state if a mouse button is released. 
This allows them to be focused until a mouse click is registered elsewhere. We 
have already implemented that functionality in the GUi_interf ace class as the 
Def ocusTextf ields method. All that's left to do now is ignore release events: 

void GUI_Textf ield : :OnRelease() {} 

Lastly, let's take a look at drawing this element: 

void GUI_Textf ield :: Draw ( sf :: RenderTarget* l_target){ 
l_target- >draw (m_visual . m_backgroundSolid) ; 
if (m_style [m_state] .m_glyph != ""){ 
l_target- >draw (m_visual . m_glyph) ; 

} 

l_target- >draw (m_visual . m_text) ; 

} 


the 

background solid behind the text that this element holds. The glyph is also 
supported here but we're not going to be using it. 
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The scrollbar element 

the existence 
of the content 

texture in order to reveal elements that are positioned further out than its size allows, 
which could be along any axis. With that knowledge, let's take a stab at working out 
the basic class definition of the scrollbar element: 

enum class SliderTypej Horizontal, Vertical }; 

class GUI_Scrollbar : public GUI_Element{ 
public : 

void SetPosition (const sf : : Vector2f & l_pos) ; 
void ApplyStyleO ; 

void UpdateStyle (const GUI_ElementState& l_state, 
const GUI_Style& l_style) ; 
private : 

SliderType m_sliderType ; 
sf : : RectangleShape m_slider; 
sf::Vector2f m_moveMouseLast ; 
int m_percentage ; 

} ; 

Firstly, we enumerate both possible types of sliders: horizontal and vertical. The 
actual GUi_Scrollbar class overwrites three of the original methods the parent 
class provides, in addition to implementing all of the purely virtual ones. 

e, which 
nformation 
of scroll it's 
currently at. 

Let's start with the easy part - the constructor: 

GUI_Scrollbar :: GUI_Scrollbar (const std :: strings l_name , 

GUI_Interf ace* l_owner) 

: GUI_Element ( l_name , GUI_ElementType :: Scrollbar , l_owner) 

{ 

m_isControl = true; 

} 

It's pretty straightforward so far. The element type is set to Scrollbar and the 
m_isControl flag is set to true to tell the owner interface which layer to draw it on. 
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Next up, the SetPosition method needs to be overwritten to make sure that the 
scrollbar is positioned correctly: 

void GUI_Scrollbar :: SetPosition ( const sf : : Vector2f& l_pos){ 
GUI_Element : : SetPosition (l_pos) ; 

if (m_sliderType == SliderType :: Horizontal ) { m_position.x = 0; } 
else { m_position.y =0; } 

} 

set to o in 

order to keep it positioned on the right edge. 

For now, the type of a scrollbar will be read in from the interface file. To make that 
happen, we may want to handle de-serialization like this: 

void GUI_Scrollbar : : Readln ( std : : stringstream& l_stream) { 
std::string type; 
l_stream >> type; 

if (type == "Horizontal ") {m_sliderType =SliderType :: Horizontal ; } 
else { m_sliderType = SliderType :: Vertical ; } 

if (m_sliderType == SliderType :: Horizontal ) { 
m_slider . SetPosition ( 0 , GetPosition ( ) .y) ; 

} 

else { m_slider . SetPosition (GetPosition ( ) .x, 0); } 

} 

Let's handle the events next, starting with OnClick: 

void GUI_Scrollbar OnClick ( const sf : : Vector2f& l_mousePos) { 
if ( ! m_slider . getGlobalBounds ( ) . contains ( 
l_mousePos - m_owner- >GetPosition ( ) ) ) 

{ 

return; 

} 

SetState (GUI_ElementState : : Clicked) ; 
m__moveMouseLast = l__mousePos; 

} 

gged, the 

state of this element is only set to clicked if the mouse coordinates are inside the 
slider. They then get stored in the m_moveMouseLast data member to prevent the 
slider from jumping. 
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mg 

the state: 

void GUI_Scrollbar : : OnRelease ( ) { 

SetState (GUI_ElementState : : Neutral) ; 

} 

void GUI_Scrollbar :: OnHover (const sf : : Vector2f& l_mousePos) { 
SetState (GUI_ElementState : : Focused) ; 

} 

void GUI_Scrollbar : : OnLeave ( ) { 

SetState (GUI_ElementState : : Neutral) ; 

} 

onality of 
the scrollbar: 

void GUI_Scrollbar :: UpdateStyle ( const GUI_ElementState& l_state, 
const GUI_Style& l_style) 

{ 

GUI_Element : : UpdateStyle ( l_state , l_style) ; 
if (m_sliderType == SliderType :: Horizontal ) { 

m_style [l_state] .m_size.x = m_owner- >GetSize ( ) .x; 

} 

else { m_style [l_state] .m_size.y = m_owner- >GetSize ( ) .y; } 

} 

e on the relevant 

axis after the parent UpdateStyle is called. 

Next, we have to define a custom way of applying style attributes to scrollbar 
elements, due to their unique nature: 

void GUI_Scrollbar : : ApplyStyle ( ) { 

GUI_Element : : ApplyStyle ( ) ; 

m_slider . setFillColor (m_style [m_state] . m_elementColor ) ; 
bool horizontal = m sliderType == SliderType :: Horizontal ; 
auto& bgSolid = m_visual .m backgroundSolid; 

SetPosition ( (horizontal ? 

sf : : Vector2f ( 0 , m_owner- >GetSize ( ) . y - bgSolid . getSize (). y) : 
sf : : Vector2f (m_owner- >GetSize ( ) . x - bgSolid . getSize (). x, 0) ) ) ; 
bgSolid . setSize ( (horizontal ? 

sf : : Vector2f (m_owner- >GetSize ( ) . x, m_style [m_state] .m_size.y) : 
sf : : Vector 2 f (m_style [m_state] . m_size . x, m_owner- >GetSize ( ) . y) ) ) ; 
m_slider . setPosition ( 

(horizontal ? m_slider . getPosition ( ) . x : GetPosition ( ) . x) , 
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(horizontal ? GetPosition ( ) .y : m_slider . getPosition (). y) ) ; 
float SizeFactor = (horizontal ? 

m_owner- >GetContentSize ( ) . x / m_owner- >GetSize ( ) . x : 
m_owner- >GetContentSize ( ) . y / m_owner- >GetSize ( ) .y) ; 
if (SizeFactor < l.f){ SizeFactor = l.f; } 
float SliderSize = (horizontal ? 

m_owner- >GetSize ( ) . x : m_owner- >GetSize ( ) .y) / SizeFactor; 
m_slider . setSize ( (horizontal ? 

sf : ; Vector2f (SliderSize , bgSolid .getSizeO .y) : 
sf : ; Vector2f (bgSolid . getSize ( ) .x, SliderSize) ) ) ; 
bgSolid. setPosition (GetPosition ( ) ) ; 

} 

After the parent ApplyStyle is invoked and the slider color is set, the position of the 
element is overwritten to keep it at 0 on the axis of action and right near the edge on 
y the size of 
er size value. 

The position of the slider is modified on the non-operational axis to always match the 
axis is as simple 
ontent size 

by the same window size. 

With the style part of this element complete, let's work on moving it and affecting its 
owner interface: 

void GUI_Scrollbar :: Update ( float l_dT) { 

// Mouse-drag code. 

if (GetStateO != GUI_ElementState :: Clicked) { return; } 
SharedContext* context = m_owner- >GetManager ( ) - >GetContext ( ) ; 
sf::Vector2f raousePos = 

sf : ; Vector2f (context- >m_eventManager- >GetMousePos ( 
context - >m_wind- >GetRenderWindow ( ) ) ) ; 
if (rrpjnoveMouseLast == raousePos) { return; } 
sf::Vector2f difference = mousePos - m_moveMouseLast ; 
m_moveMouseLast = mousePos; 

bool horizontal = msliderType == SliderType :: Horizontal ; 
m_slider . move ( (horizontal ? difference. x : 0), 

(horizontal ? 0 : dif ference .y) ) ; 
if (horizontal && m_slider . getPosition (). x < 0) { 
m_slider . setPosition ( 0 , m_slider . getPosition ( ) .y) ; 

} else if (m_slider . getPosition ( ) .y < 0) { 

m_slider . setPosition (m_slider . getPosition ( ) .x, 0) ; 

} 
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if (horizontal&& (m_slider . getPosition ( ) . x+m_slider . getSize ( ) .x > 
m_owner- >GetSize ( ) . x) ) 

{ 

m_slider . setPosition ( 

m_owner- >GetSize ( ) . x - m_slider . getSize (). x, 
m_slider.getPosition() .y) ; 

} else if (m_slider . getPosition ( ) .y + m_slider . getSize ( ) .y > 
m_owner- >GetSize ( ) .y) 

{ 

m_slider .setPosition (m_slider . getPosition ( ) . x, 
m_owner- >GetSize ( ) .y - m_slider . getSize ( ) .y) ; 

} 

float WorkArea = (horizontal ? 

m_owner- >GetSize ( ) . x - m_slider . getSize (). x : 
m_owner- >GetSize ( ) .y - m_slider . getSize ( ) .y) ; 
int percentage = ( (horizontal ? 

m_slider . getPosition (). x : m_slider . getPosition (). y) / 
WorkArea) * 100; 

if (horizontal)! m_owner- >UpdateScrollHorizontal (percentage) ; } 

else { m_owner- >UpdateScrollVertical (percentage) ; } 

SetRedraw (true) ; 

} 

merit is 
Clicked 

and down. If the current mouse position is not the same as the last position from 
current 

position of the mouse is stored for later reference. 

tween the last 
s of the interface, 

in which case, its position gets reset to the closest edge. 

's position 
size. The 
marked 

to be re-drawn to reflect its changes. 

The last thing we need to do is define how the scrollbar element is drawn: 

void GUI_Scrollbar : : Draw ( sf ; : RenderTarget* l_target) { 
l_target- >draw (m_visual . m_backgroundSolid) ; 
l_target- >draw (m_slider) ; 

} 


expanded to 
support textures as well. 
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Integrating the GUI system 

In order to use the GUI system, it needs to first exist. Just like in previous chapters, 
by adding 

the GUI manager and the font manager to the SharedContext . h file: 

struct SharedContext { 

SharedContext () : 

m_f ontManager (nullptr ) , 

m_guiManager (nullptr) { } 

FontManager* m_f ontManager ; 

GUI_Manager* m_guiManager ; 

} ; 

We need to keep a pointer to the GUI manager and the font manager in the Game 
class, as with all of the other classes that are shared through the SharedContext 
structure, starting with the header: 

class Game{ 
public : 

private : 

FontManager m_f ontManager ; 

GUI_Manager m_guiManager ; 

} ; 


These pointers are, of course meaningless, unless they actually point to valid objects 
in memory. Let's take care of the allocation and de-allocation of resources in the 
Game . cpp file: 


Game :: Game () : m_window (" Chapter 11", sf : : Vector2u (800 , 600)), 

m_entityManager ( &m_systemManager , &m_textureManager ) , 
m_stateManager ( &m_context ) , 

m_guiManager (m_window . GetEventManager ( ) , &m_context ) 

{ 


m_context . m_guiManager = &m_guiManager ; 
m_f ontManager . RequireResource ( "Main" ) ; 

} 
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Game : : -Game ( ) { 

m_f ontManager . ReleaseResource ( "Main" ) ; 

} 

Next, we can look at updating all of the interfaces in the application and handling 
GUI events: 

void Game :: Update () { 

m_context . m_guiManager- >Update (m_elapsed . asSeconds ( ) ) ; 

GUI_Event guiEvent ; 

while (m_context , m_guiManager- >PollEvent (guiEvent ) ) { 
m_window . GetEventManager ( ) - >HandleEvent (guiEvent) ; 

} 

} 

Note that the GUl_Event instance is forwarded to the EventManager class. We're 
going to be expanding it soon. 

Finally, let's handle drawing our interfaces: 

void Game :: Render () { 

m_stateManager . Draw ( ) ; 

sf::View CurrentView = m_window . GetRenderWindow ()- >getView () ; 
m_window . GetRenderWindow ( ) - >setView ( 

m_window . GetRenderWindow ( ) - >getDef aultView ( ) ) ; 
m_context . m_guiManager- >Render (m_window- >GetRenderWindow ( ) ) ; 
m_window . GetRenderWindow ( ) - >setView (CurrentView) ; 

m_window . EndDraw ( ) ; 

} 
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window 

view has to be set to the default before the interfaces are drawn. It then needs to 
ht look 

something like this: 



Expanding the event manager 

n in order 
iting all 

of that extra code, we're going to use something that was built solely for the purpose 
of handling them: the event manager. 

Let's start by expanding the EventType enumeration to support GUI events: 
enum class EventType { 


Keyboard = sf :: Event :: Count + 1, Mouse, Joystick, 


GUI_Click, GUI_Release , GUI_Hover, GUI_Leave 

} ; 


It's important to keep these custom event types at the very bottom of the structure 
because of the way the code we've written in the past works. 

Our previous raw implementation of the EventManager class relied on the fact that 
events, 

such as key bindings, fit into that category but a lot of other event types, especially 
custom events, require additional information in order to be processed correctly. 
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ure like this: 

struct EventInfo{ 

EventInfo(){ l_code =0; } 

Eventlnf o ( int l_event) { l_code = 1 event; } 

Eventlnf o (GUI_Event l_guiEvent) { l_gui = l_guiEvent; } 
unionj 

int l_code ; 

GUI_Event l_gui ; 

} ; 

} ; 


eric 

e GUI_Event 

structure. GUl_Event belongs to a union, which is why it couldn't use std : : string 
typed data members. 

If the boost library is used, all of this code can be reduced to 
boost :: variantcint , GUI_Event>. 

One additional change is that we want to be able to pass the GUI event information 
be held by our 
EventDetails structure: 

struct EventDetails { 

EventDetails (const std :: strings l_bindName) 

: m_name (l_bindName) { Clear (); } 

std::string m_guilnterf ace ; // GUI interface name, 
std:: string m_guiElement ; // GUI element name. 

GUI_EventType m_guiEvent ; / / GUI event type . 

void Clear ( ) { 

m_guilnterf ace = 

m_guiElement = " " ; 

m_guiEvent = GUI_EventType : : None ; 

} 

} ; 
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Now, let's adjust the Binding structure: 
struct Binding{ 

Binding ( const std : : strings l_name) : m_name ( l_name ) , 
m_details (l_name) , c ( 0 ) { } 

-Binding ( ) { 

// GUI portion. 

for (auto itr = mevents . begin () ; 
itr != m_events . end ( ) ; ++itr) 

{ 

if (itr->first == EventType : :GUI_Click | j 
itr->first == EventType :: GUI_Release | j 
itr->first == EventType :: GUI_Hover | j 
itr->first == EventType : :GUI_Leave) 

{ 

delete [] itr- >second . m_gui . m_interf ace ; 
delete [] itr- >second . m_gui . m_element ; 

} 

} 

} 


We had to use const char* data types to hold element and interface names because 
is memory 
f the event 
GUI event 

types, in which case the memory is safely de-allocated. 
ading the 

HandleEvent method with a different argument type seems like a good choice here: 

void HandleEvent ( sf :: Events l_event); 
void HandleEvent (GUI_EventS l_event) ; 

We need to make sure that no GUI events are processed in the original 
HandleEvent method: 

void EventManager :: HandleEvent ( sf :: Events l_event) { 

for (auto Se_itr : bind- >m_events) { 

EventType sfmlEvent = (EventType) l_event . type; 
if (e_itr. first == EventType :: GUI_Click | 
e_itr. first == EventType :: GUI_Release | 
e_itr. first == EventType :: GUI_Hover | 
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e_itr. first == EventType : : GUI_Leave) 

{ 

continue ; 

} 


Handling the 

GUI events themselves is quite simple and can be done in this manner: 

void EventManager : : HandleEvent (GUI_Event& l_event) { 
for (auto &b_itr : m_bindings) { 

Binding* bind = b_itr . second; 
for (auto &e_itr : bind- >m_events ) 

{ 

if (e_itr. first != EventType :: GUI_Click && 
e_itr. first != EventType :: GUI_Release && 
e_itr. first != EventType :: GUI_Hover && 
e_itr. first != EventType :: GUI_Leave) 

{ continue; } 

if ( (e_itr . first == EventType :: GUI_Click && 
l_event . m_type != GUI_EventType :: Click) | 

(e_itr. first == EventType :: GUI_Release && 
l_event . m_type != GUI_EventType :: Release) | 

(e_itr. first == EventType :: GUI_Hover && 
l_event . m_type != GUI_EventType : :Hover) j 
(e_itr. first == EventType :: GUI_Leave && 
l_event . m_type != GUI_Event Type :: Leave) ) 

{ continue; } 

if ( strcmp (e_itr . second . m_gui . m_interf ace , 
l_event . m_interface) \ 

strcmp (e_itr . second . m_gui . m_element , l_event .m_element) ) 
{ continue; } 

bind- >m_details . m^guilnterf ace = l_event . m_interf ace ; 
bind- >m_details . m_guiElement = l_event . m_element ; 

++ (bind->c) ; 

} 

} 

} 
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. Anything 
t matches 

the type inside the binding, additional information is checked in the Eventlnfo 
hey are 

recorded as event details and the event count is incremented. 

The last chunk of code that needs attention is the LoadBindings method. We need 
to adjust it to support interface and element name-loading from the keys . cf g file, 
which should look something like this: 

Key_X 5:23 

MainMenu_Play 27 : MainMenu : Play 

The fiUI event, 

which requires two identifiers to be loaded instead of just one. Let's adjust it: 

void EventManager : : LoadBindings () { 

while ( ! keystream . eof ( ) ) { 
std: : string keyval; 
keystream >> keyval; 
int start = 0; 

int end = keyval . find (delimiter) ; 
if (end == std :: string :: npos ) { 
delete bind; 
bind = nullptr; 
break ; 

} 

EventType type = EventType ( 

stoi (keyval . substr (start, end-start) ) ) ; 

Eventlnfo eventlnfo; 
if ( type==EventType : : GUI_Click | | 
type==EventType : :GUI_Release | | 
type == EventType: :GUI_Hover | j 
type == EventType :: GUI_Leave) 

{ 

start = end + delimiter . length () ; 
end = keyval . find (delimiter , start); 

std:: string window = keyval . substr ( start , end - start); 

std:: string element; 

if (end != std :: string :: npos) { 

start = end + delimiter . length () ; 

end = keyval . length () ; 

element = keyval . substr ( start , end); 


[ 344 ] 



Chapter 11 

} 

char* w = new char [window. length ( ) +1]; // +1 for \0 
char* e = new char [element . length ( ) + 1]; 

// Size in bytes is the same as character length. 1 char = IB. 
strcpy s (w, window. length ( ) + 1, window. cstr ()) ; 
strcpy_s(e, element . length ( ) + 1, element . c_str ()) ; 

eventlnfo .m_gui .m_interf ace = w; 
eventlnf o .m_gui .m_element = e; 

} else { 

int code = stoi (keyval . substr (end + delimiter . length () , 
keyval . find (delimiter , end + delimiter . length ()))) ; 
eventlnf o . m_code = code; 

} 

bind- >BindEvent (type , eventlnfo) ; 

} 


atches any of the 
ied to the 

newly allocated memory of char* via the std: : strcpy method. 



Keep in mind that when memory for char* types is allocated to match 

n g 

character at the end. 


] 


Re-implementing the main menu 

this way, 

let's re-construct the main menu, starting by creating its . interface file: 


Interface MainMenu MainMenu . style 0 0 Immovable NoTitle "Main menu" 
Element Label Title 100 0 MainMenuTitle . style "Main menu:" 

Element Label Play 0 32 MainMenuLabel . style "PLAY" 

Element Label Credits 0 68 MainMenuLabel . style "CREDITS" 

Element Label Quit 0 104 MainMenuLabel . style "EXIT" 
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d have no 

title bar. All three buttons in this interface, as well as its title, can be represented by 
labels with different styles. Speaking of which, let's take a look at the style of our 
main menu interface: 


State Neutral 
Size 300 150 
TextSize 12 
Font Main 
/ State 


As you can see, it only defines the most basic attributes and does not aim to be 
visually responsive by itself. The button label style, however, is a little different: 


State Neutral 

Size 300 32 

BgColor 255 0 0 255 

TextColor 255 255 255 255 

TextSize 14 

Font Main 

TextPadding 150 16 

TextOriginCenter 

/ State 


State Hover 
BgColor 255 100 0 255 
/ State 


State Clicked 
BgColor 255 150 0 255 
/ State 


, unlike the 

label that represents the title of the main menu: 


State Neutral 
Size 118 32 

TextColor 255 255 255 255 
TextSize 24 
Font Main 
/ State 
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class State_MainMenu : public BaseState{ 

public : 

void Play (EventDetails* l_details) ; // Callback, 
void Quit (EventDetails* l_details) ; // Callback. 

} ; 

In addition to all of the required methods that a state has to implement, we only need 
two callbacks to handle GUI clicks. This is all set up in the OnCreate method of the 
main menu state: 

void State_MainMenu :: OnCreate () { 

GUI_Manager* gui = m_stateMgr- >GetContext ( ) ->m_guiManager; 
gui->LoadInterface (StateType : :MainMenu, 

"MainMenu . interface " , "MainMenu") ; 
gui->GetInterface (StateType : :MainMenu, 

"MainMenu" ) - >Set Position (sf: : Vector2f (250. f, 168 . f ) ) ; 

EventManager* eMgr = m_stateMgr- >GetContext ( ) ->m_eventManager; 
eMgr- >AddCallback (StateType : : MainMenu, 

"MainMenu_Play" , &State_MainMenu : : Play, this); 
eMgr- >AddCallback (StateType : : MainMenu, 

"MainMenu_Quit " , &State_MainMenu : : Quit , this); 

} 

Firstly, the main menu interface is loaded from a file and placed on screen. The event 
manager is then used to set up callbacks for the Play and Quit button actions. This is 
already much cleaner than the previous approach. 

oved, as 
shown here: 

void State_MainMenu : :OnDestroy() { 

m_stateMgr- >GetContext ( ) - >m_guiManager- > 

Removelnterf ace (StateType : :MainMenu, "MainMenu") ; 

EventManager* eMgr = m_stateMgr- >GetContext ( ) - >ra_eventManager ; 
eMgr- >RemoveCallback (StateType : :MainMenu, "MainMenu_Play" ) ; 
eMgr- >RemoveCallback (StateType : :MainMenu, "MainMenu_Quit " ) ; 

} 
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The text of the Play button must be changed if a GAME state exists: 

void State_MainMenu :: Activate () { 

auto& play = *m_stateMgr- >GetContext ( ) - >m_guiManager- > 

Getlnterf ace (StateType : :MainMenu, "MainMenu" ) - > 

GetElement ( " Play" ) ; 

if (m_stateMgr- >HasState (StateType : :Game)) { 

// Resume 

play . SetText ( "Resume" ) ; 

} else { 

// Play 

play . SetText ( " Play" ) ; 

} 

} 

That leaves us with our two callbacks, which look like this: 

void State_MainMenu: : Play (EventDetails* l_details) { 
m_stateMgr- >SwitchTo (StateType : :Game) ; 

} 

void State_MainMenu :: Quit (EventDetails* l_details){ 
m_stateMgr- >GetContext ( ) - >m_wind- >Close ( ) ; 

} 

roved event 

manager for fast and responsive results. The main menu was created with roughly 
20 lines of code, or fewer, and looks like this: 


Main menu: 

K Play 

CREDITS 

EXIT 
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Summary 

At the beginning of Chapter 10, Can I Click This? - GUI Fundamentals, our main goal 

pplication. 

anagement, 

code 

to the GUI 
system 

that is capable of producing efficient, responsive, and fast results with the minimum 
amount of effort and code. Furthermore, you should now have the skills necessary 
to build even more element types that will enable this system to do amazing things. 

In the next chapter, we're going to be covering the management and usage of sound 
and music elements in SFML. See you there! 
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Can You Hear Me Now? 
- Sound and Music 


There's nothing quite like the enjoyment of being immersed in a virtual environment, 
many 

human senses as possible can either make or break the captivation that a form of 
f ever, be 

only down to visual effects. Throughout this chapter, we will briefly close our eyes 
h as: 

• Basics of sound and music in SFML 

• Placement of sounds and the listener in 3D space 

• Proper management and recycling of sound instances 

• Expansion of the entity component system to allow for sounds 

We have a long way to go until our first sonic boom, so let's dive right in! 

Use of copyrighted resources 

Throughout 

this chapter, we're going to use the following resources: 

• Fantozzi's Footsteps (Grass/Sand & Stone) by Fantozzi under the CCO license 
(public domain): http : //opengameart . org/ content/ f antozzis- 
foot steps -grass sand- stone 

• Electrix (NES Version) by Snabisch under the CC-BY 3.0 license: 
http : / / opengameart . org/ content/electrix-nes-version 

• Town Theme RPG by cynicmusic under the CC-BY 3.0 license: 
http : / / opengameart . org/ content/ town- theme -rpg 
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Preparing the project for sound 

In order to successfully compile a project that uses SFML audio, we need to make 
sure these additional dependency . 1 ib files are included: 

• sfml-audio-s . lib 

• openal32.1ib 

• flac.lib 

• ogg.lib 

• vorbis.lib 

• vorbisenc . lib 

• vorbisf ile . lib 

Additionally, the executable file must always be accompanied by the openal32 . dll 
file, which comes with SFML and can be found inside the bin folder of the library. 


Basics of SFML sound 

Anything audio related falls into one of two categories within SFML: sf : : Sound that 
represents short sound effects, or sf : : Music that is used to play longer audio tracks, 
ntinuing 

further. Let's talk about each one individually. 

Playing sounds 

The sf : : Sound class is extremely lightweight and should only ever be used to 
stores and 

utilizes actual audio files is by using a sf : : SoundBuf f er instance. It is analogous 
to sf : : Sprite and the way it uses an instance of sf : : Texture for drawing. The 
sf : : SoundBuf fer is used to hold audio data in memory, which the sf : : Sound 
class then reads and plays from. It can be used as follows: 

sf :: SoundBuf fer buffer; 

buffer . loadFromFile ( " Some Sound . ogg" ) ; 

sf::Sound sound (buffer) ; 

sound. setBuf fer (buffer) ; // Alternative. 

As you can see, a sound buffer can be attached to an instance of sf : : Sound by 
either passing it to the sound's constructor or by using the setBuf fer method 
of a sound instance. 
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As long as the sound is expected to be playing, the 
sf : : SoundBuf f er instance shouldn'tbe destroyed! 

After the sound buffer loads the sound file and is attached to an instance of 
sf : : Sound, it can be played by invoking the play ( ) method: 

sound. play () ; // Play the sound! 

It can also be paused and stopped by using the appropriately named pause ( ) and 
stop ( ) methods: 

sound. pause () ; // Pause the sound, 
sound. stop () ; // Stop the sound. 

Obtaining the current status of a sound to determine if it's playing, paused, or 
stopped can be done like this: 

sf :: SoundSource :: Status status = sound . getStatus () ; 

The status it returns is a simple enumeration of three values: stopped, paused, 
and playing. 

Lastly, we can adjust the sound's volume, pitch, whether it loops or not, and how far 
the sound has progressed by using these methods respectively: 

sound . setVolume ( 100 . f ) ; // Takes in a float, 
sound. setPitch (1 . f) ; // Takes in a float, 
sound. setLoop (true) ; // Takes in a Boolean. 

sound. setPlayingOff set (sf :: seconds (5 . f) ) ; // Takes in sf::Time. 

Audio pitch is simply a numeric value that represents frequency of the sound. Values 
above 1 will result in the sound playing at a higher pitch, while anything below 1 has 
s playing speed. 

Playing music 

Any sf : : Music instance supports all of the methods discussed previously, except 
setBuf f er. As you already know, sf : : Sound uses instances of sf : : SoundBuf fer 
that it reads from. This means that the entire sound file has to be loaded in memory 
for it to be played. With larger files, this quickly becomes inefficient, and that's the 
reason sf : : Music exists. Instead of using buffer objects, it streams the data from the 
file itself as the music plays, only loading as much data as it needs for the time being. 
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Let's take a look at an example: 
sf:: Music music; 

music . openFromFile ( "SomeMusic . ogg" ) ; 
music .play ( ) ; 

music . stop ( ) ; 

Notice the name of the method openFromFile. In contrast, where sound buffers load 
files, sf : : Music merely opens it and reads from it. 

A very important thing to mention here is that sf : : Music is a non-copyable class! 
t in an error: 

sf:: Music music; 

sf::Music music2 = music; // ERROR! 

Passing a music instance to a function or a method by value would also produce the 
same results. 

Sound spatialization 

Both sf : : Sound and sf : : Music also support spatial positioning. It takes advantage 
ually playing 

around you. There is a catch, though. Every sound or music instance that is desired 
wn as a 

monophonic or mono sound, as opposed to stereo that already decides how the 
speakers are used. 

The way sounds are perceived in three-dimensional space is manipulated through a 
single, static class: sf : : Listener. It's static because there can only ever be one listener 
per application. The main two aspects of this class we're interested in are the position 
and direchon of the listener. Keep in mind that although we may be working on a 2D 
game, SFML sounds exist in 3D space. Let's take a look at an example: 

sf :: Listener :: setPosition (5 . f , O.f, 5.f); 
sf :: Listener :: setDirection (1 . f , O.f, O.f); 
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First, let's address the three-dimensional coordinates. In SFML, the default up vector 
is on the positive Y axis. Look at the following figure: 


Y+ 

1(0, 1, 0) - Up vector. 



ensions 

This arrangement of axes is known as a right-handed Cartesian coordinate system and 
is that 

what we've been calling the Y axis in two dimensions is really the Z axis in a three 
dimensional space. That's important to keep in mind if we want to have correct 
results when moving sound through space. 

also referred 

to as a normalized vector, which means it can only have a maximum magnitude of 
zed again, so 

these two lines of code would produce equivalent results of a south-east direction: 

sf :: Listener :: setDirection ( 1 . f , O.f, l.f); 
sf :: Listener :: setDirection ( 0 . 5f , O.f, 0.5f); 

tions, 
face four 

possible directions. 

Placing sounds in space 

Much like how sprites are positioned in two-dimensional space, sounds can be 
positioned as well by using the method with the same name: 

sf::Sound sound; 

sound. setPosition (5 . f , O.f, 5 . f ) ; 


[ 355 ] 


Can You Hear Me Now? - Sound and Music 


Let's say that the listener is facing in the positive X direction (l.f Of O.f). The sound 
that we just placed at coordinates ( 5f Of 5.J) would be five units ahead and five 
units to the right of our listener and would be heard through the right speaker. How 
e and 

attenuation come in: 

sound. setMinDistance (6 . f ) ; 
sound. setAttenuation (2 . f ) ; 

Sound minimum distance is the threshold at which the sound begins to lose volume 
exactly six 

units of distance away from the sound source, full volume of the sound will be 
ned by 

the attenuation factor. Consider this figure: 



The circle with a radius of Min_Distance represents an area, where the sound can be heard at maximum 
volume. After the minimum distance is exceeded, the attenuation factor is applied to the volume. 


ter sound fades 
erywhere, 
r is very 
close to it. 


Remember that although we're not going to be taking advantage of it, music in 
SFML behaves under the same rules of spatialization as sound, as long as it only 
has one channel. 


[ 356 ] 


Chapter 12 


Audio manager 

to manage 

sf : : SoundBuf fer instances easily. Luckily, our ResourceManager class is there to 
make it extremely convenient, so let's create the AudioManager . h file and define 
the way sound buffers are set up: 

class AudioManager : public ResourceManager< 

AudioManager, sf :: SoundBuf fer> 

{ 

public : 

AudioManager ( ) : ResourceManager ( "audio . cfg" ){ } 

sf :: SoundBuf fer* Load(const std::string& l_path) { 
sf :: SoundBuf fer* sound = new sf :: SoundBuf fer () ; 
if (! sound- >loadFromFile ( 

Utils :: GetWorkingDirectory ( ) + l_path) ) 

{ 

delete sound; 
sound = nullptr; 

std::cerr << "! Failed to load sound: " 

<< l_path << std::endl; 

} 

return sound; 

} 

} ; 

same as that 

of textures or fonts. Similar to the previous resource managers, we also provide 
a file that paths are loaded from. In this case, it is the audio . cfg file: 

Footstep media/Audio/ footstep . ogg 
TownTheme media/Audio/TownTheme . ogg 

Once again, it is just like dealing with textures or fonts. So far, so good! 
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Defining sound properties 

Sound, much like any other medium, has a few different properties of interest that 
are up for tweaking. The effects we're going to be playing in our game don't just 
ance a sound 
e're going 

to store this information is defined in SoundProps . h: 
struct SoundProps { 

SoundProps (const std::string& l_name) : m_audioName (l_name) , 
m_volume (100) , m_pitch (1 . f ) , m_minDistance (10 . f ) , 
m_attenuation ( 10 . f ) { } 
std: : string m_audioName; 
float m_volume; 
float m pitch; 
float m_minDistance ; 
float m_attenuation; 

} ; 

In additiondentifier 

of the audio file that a sound is going to be using. A typical sound file for our 
application would look something like footstep . sound: 

Audio Footstep 
Volume 25 
Pitch 1 . 0 
Distance 150 
Attenuation 2 

With this out of the way, we can actually jump right into managing the sf : : Sound 
instances! 

Managing sounds 

tion, it's 
here the 

SoundManager class comes in. Let's begin aliasing a data type for sound IDs: 
using SoundID = int; 

A simple integer type is more than qualified for the job of keeping sounds identified. 
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ce: 


struct SoundInfo{ 

Soundlnfo ( const std :: strings l_name) : 

m_name (l_name) , m_manual Paused (false) { } 
std::string m_name; 
bool m_manualPaused; 

} ; 


want to store 

the string identifier of the audio file that the sound is using. Keeping track of whether 
ncy. That's 

what the m_manualPaused Boolean flag is there for. 
type 

definitions used here is essential: 

using SoundProperties = std :: unordered_map<std :: string, 

SoundProps> ; 

using SoundContainer = std : : unordered_map<SoundID, 
std: :pair<SoundInfo, sf : :Sound*>>; 
using Sounds = std : : unordered_map<StateType , SoundContainer> ; 
using RecycledSounds = std : : vector<std : : pair< 
std: : pair<SoundID , std : : string> , sf :: Sound* >> ; 
using MusicContainer = std : : unordered_map<StateType , 
std: :pair<SoundInfo, sf : :Music*>>; 

The SoundProperties type is just a map that associates the name of a sound to 
a structure that contains its properties. SoundContainer is another map that ties 
a SoundlD to a pair that contains the Soundlnfo structure, as well as the actual 
instance of the sf : : Sound object. The Sounds data type is responsible for grouping 
these sound containers by state. 

a different 

container of type RecycledSounds. It stores the sound ID and name alongside the 
sf : : Sound instance. 

The last type definition we're going to be dealing with here is a container for 
sf : : Music instances. Just like sounds, they're grouped by states. One major 
difference here is the fact that we're only allowing one instance of sf : : Music 
per state, which is stored together with a Soundlnfo structure. 
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Now that we have everything we need, let's take a look at the sound manager 
header file: 

class SoundManager { 
public : 

SoundManager (AudioManager* l_audioMgr) ; 

-SoundManager ( ) ; 

void ChangeState (const StateType& l_state) ; 
void RemoveState (const StateTypek l_state) ; 

void Update (float l_dT) ; 

SoundID Play(const std::string& l_sound, 
const sf : : Vector3f & l__position, 
bool l_loop = false, 
bool l_relative = false) ; 
bool Play (const SoundID& l_id) ; 
bool Stop (const SoundID& l_id) ; 
bool Pause (const SoundID& l_id) ; 

bool PlayMusic (const std::string& l_musicld, 
float l_volume = 100. f, bool l_loop = false) ; 
bool PlayMusic (const StateType& l_state) ; 
bool StopMusic (const StateType& l_state) ; 
bool PauseMusic (const StateType& l_state) ; 

bool SetPosition (const SoundID& l_id, const sf : : Vector3f& l_pos) ; 
bool IsPlaying (const SoundID& l_id) ; 

SoundProps* GetSoundProperties (const std : : strings l_soundName) ; 

static const int Max_Sounds = 150; 
static const int SoundCache = 75; 

private : 

bool LoadProperties ( const std::string& l_file) ; 
void PauseAll (const StateType& l_state) ; 
void UnpauseAll (const StateType& l_state) ; 

sf:; Sound* CreateSound (SoundID& l_id, 
const std::string& l_audioName) ; 
void SetUpSound (sf :: Sound* l_snd, const SoundProps* l_props, 
bool l_loop = false, bool l_relative = false) ; 
bool RecycleSound (const SoundID& l_id, sf::Sound* l_snd, 
const std::string& l_name) ; 
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void Cleanup (); 

Sounds m_audio; 

MusicContainer m_music; 
RecycledSounds m_recycled; 
SoundProperties m_properties ; 
StateType m_currentState ; 

SoundID m_lastID; 
unsigned int m_numSounds; 
float m_elapsed; 

AudioManager* m_audioManager ; 

}; 


As mentioned previously, it's a good idea to keep the number of sf : : Sound and 
sf : : Music instances in your application down to a designated limit that never 
exceeds 256. In this case, we're playing it pretty safe by using static data members for 
setting a limit of 150 sounds loaded in memory at the same time. In addition to that, 
efore they're 

used again, which is 75. These values can obviously be tweaked to your liking, 
to 

implementation details. As expected, the sound and music containers are stored in 
this class under the names m_audio and m_music. Additionally, we're storing all of 
the sound properties in this class, alongside the recycled sound container. Because 
sound functionality is state based, the m currentstate data member is necessary 
for keeping tabs on what state the application is running in. 

In order to assign sound IDs properly, keeping track of the last ID is a good 
idea, hence m_lastlD. Also, since enforcing restrictions on how many instances 
of sf : : Sound and sf : : Music can be "alive" at the same time is of paramount 
importance; m_numSounds is used to keep track of every instance of these two classes, 
is what 

m_elapsed will be used for. 

gement 
and retrieval. 
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Implementing the sound manager 

Let's begin, as always, by looking at the constructor and destructor of this class: 

SoundManager : : SoundManager (AudioManager* l_audioMgr) 

: m_lastID(0), m_audioManager ( l_audioMgr ) , 
m_elapsed ( 0 . f ) , m_numSounds ( 0 ) { } 

SoundManager :: -SoundManager () { Cleanup () ; } 

A pointer to an AudioManager instance is obtained through the argument list of the 
constructor and initialized in the initializer list, alongside other data members and 
their default values. The destructor simply invokes another method called Cleanup ( ) , 
which is responsible for the de-allocation of memory. It will be covered shortly. 

We have already discussed the role that application states play in sound management. 
Now, let's take a look at actually defining the behavior of sound when states 
are changed: 

void SoundManager :: ChangeState (const StateType& l_state) { 

PauseAll (m_currentState) ; 

UnpauseAll (l_state) ; 
m_currentState = l_state; 

if (npjnusic . f ind (m_currentState) != m_music . end ( ) ) { return; } 

Soundlnfo info ( " " ) ; 

sf : : Music* music = nullptr; 

m_music . emplace (m_currentState , std: :make_pair (info, music)); 

} 

Upon the application state being altered, a PauseAll method is invoked with the 
argument of m_currentstate. It’s responsible for effectively silencing every sound 
that is currently playing. We don't want to be hearing fights and explosions of the 
in-game action while we're in the main menu. The UnpauseAll method is called next, 
with the identifier of the state being changed to being passed in as the argument, 
e state, 
ffects. The 

data member that holds the current state information is then altered. 

The last few lines of code in this method are responsible for making sure that the 
, some blank 

information is inserted into the m_music container in order to signify that the current 
state currently has no music playing. 
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Next, let's talk about what happens when a state is removed from the application: 

void SoundManager :: RemoveState (const StateType& l_state) { 
auto& StateSounds = m_audio . f ind ( l_state) - >second; 
for (auto &itr : StateSounds) { 

RecycleSound (itr. first, itr. second . second, 
itr . second . first . m_name) ; 

} 

m_audio . erase (l_state) ; 
auto music = mmusic . f ind (l_state) ; 
if (music == m_music . end ( ) ) { return; } 
if (music->second. second) { 
delete music- >second . second; 

- -m_numSounds ; 

} 

m_music . erase (l_state) ; 

} 

The sound container is first obtained for the state that is being removed. Every sound 
in that state is then iterated over and recycled via the RecycleSound method, which 
takes in the sound ID, pointer to the sf : : Sound instance, and the sound name. 

Once that is done, all of the state information is erased from the m_audio container. 
Additionally, if an instance of sf : :Music is found in that state, the memory for it is 
deallocated and the number of sounds currently existing in memory is decreased. 

ne of 

the main reasons we're using manager classes instead of simply having resources 
mess in 

this case might look a little something like this: 

void SoundManager :: Cleanup () { 
for (auto &state : m_audio) { 

for (auto &sound ; state . second) { 

m_audioManager- >ReleaseRe source ( sound . second .first . m_name) ; 
delete sound . second . second; 

} 

} 

m_audio . clear ( ) ; 

for (auto &recycled : m_recycled) { 

m_audioManager- >ReleaseResource (recycled . first . second) ; 
delete recycled. second; 

} 

m_recycled . clear ( ) ; 
for (auto &music ; m_music) { 
if (music . second . second) { 
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delete music . second. second; 

} 

} 

m_music . clear ( ) ; 

m_properties . clear ( ) ; 
m_numSounds = 0 ; 
m__lastID = 0; 

} 

First, we iterate over the container of currently playing sounds and release the audio 
resources that are being used. The dynamic memory for the sound is then deleted 
safely instead of being recycled. The exact same process is repeated one more time 
for all of the sounds that exist in the m recycled container. Finally, all of the music 
e number of 

sounds is set back to 0, along with the last sound ID. 
ook at how 

we can make a system like this tick through its Update method: 

void SoundManager :: Update ( float l_dT) { 
m_elapsed += l_dT; 
if (m_elapsed < 0.33f){ return; } 

// Run once every third of a second. 
m_elapsed = 0; 

auto& container = m_audio [m_currentState] ; 

for (auto itr = container . begin () ; itr != container . end ();) { 
if ( ! itr- >second . second- >get Status ( ) ) { 

RecycleSound (itr->first, itr- > second . second, 
itr- >second . first . m_name) ; 
itr = container . erase ( itr ) ; // Remove sound, 
continue ; 

} 

+ + i t r ; 

} 

auto music = m_music . f ind (m_currentState) ; 

if (music == m_music . end ( ) ) { return; } 

if ( !music->second. second) { return; } 

if (music->second. second- >getStatus ()) { return; } 

delete music- >second . second; 

music- >second . second = nullptr; 

- -m_numSounds ; 

} 
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An important thing to keep in mind here is that we really don't need to run this 
ck of time 

passing and check the m_e lapsed data member each cycle to see if it's time to run 
our code yet. The o . 3 3 f value is arbitrary in this case and can be set to anything 
within a reasonable range. 

If enough time has passed, we loop over every sound in the current state and 
invoking the 

RecycleSound method and then remove it from our primary sound container. 

When an element in an STL container is removed, all iterators of said 

being skipped or out of bounds accesses. It can be addressed by setting 
the iterator to the return value of the erase method, as it returns a valid 
iterator to an element after the one that has been erased. It increments the 
of 

the loop. 

In this system, music follows the exact same treatment and is removed if it's no 
longer playing. 

sounds: 

SoundID SoundManager :: Play (const std : : string& l_sound, 

const sf : : Vector3f & l_position, bool l_loop, bool l_relative) 

{ 

SoundProps* props = GetSoundProperties ( l_sound) ; 

if (! props ) { return -1; } // Failed to load sound properties. 

SoundID id; 

sf::Sound* sound = CreateSound ( id, props- >m_audioName) ; 
if ( Isound) { return -1; } 

// Sound created successfully. 

SetUpSound (sound, props, l_loop, l_relative) ; 
sound->setPosition (l_position) ; 

Soundlnfo info (props- >m_audioName) ; 

m_audio [m_currentState] . emplace ( id, std : : make_pair ( inf o , sound) ) ; 
sound- >play ( ) ; 
return id; 

} 
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We begin by obtaining a pointer to the sound properties structure by using the 
GetSoundProperties method, which we will be covering later. If it returned 
a nullptr value, -1 is returned by the Play method to signify a loading error, 
e passed in 

by reference to the CreateSound method, along with the identifier of the audio sound 
buffer. If the sound was created successfully, it returns a pointer to the sf : : Sound 
instance that is ready to be used. 

The SetUpSound method is then invoked with pointers to the sf : : Sound instance and 
properties being passed in as arguments, as well as two Boolean flags for whether 
the sound should loop and be relative to the listener. The latter two are passed in 
as arguments to the Play method we're currently implementing. The sound is then 
positioned in space and stored in the m_audio container, along with the Soundlnf o 
structure that is set up just one line before and holds the audio identifier. 

The final step is then calling the play ( ) method of our sound instance and returning 
the ID of said sound for later manipulations. 

As the header file suggests, there are two versions of the Play method. Let's cover 
the other one now: 

bool SoundManager :: Play (const SoundID& l_id) { 
auto& container = maudio [m_currentState] ; 
auto sound = container . find (l_id) ; 
if (sound == container . end ()) { return false; } 
sound- >second. second- >play ( ) ; 
sound- >second . first . m_manual Paused = false; 
return true; 

} 

This version of the Play method only takes in a single argument of the sound ID 
and returns a Boolean flag. It's meant to start an already existing sound, which 
begins by it being located in the sound container. If the sound has been found, 
its play method is invoked and the m_manualPaused flag is set to false, showing 
that it is no longer paused. 

Stopping a sound works in a very similar fashion: 

bool SoundManager :: Stop (const SoundID& 1 id) { 

auto& container = m_audio [m_currentState] ; 

auto sound = container . find (l_id) ; 

if (sound == container . end ()) { return false; } 

sound- >second . second- >stop ( ) ; 

sound- >second . first . m_manual Paused = true; 

return true; 

} 
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The only difference here is that the stop method is invoked instead, and the 
m_manual Paused flag is set to true to signify that it has been paused in a non- 
automatic fashion. 

One more method that follows the exact same pattern is the Pause method: 

bool SoundManager :: Pause (const SoundID& l_id) { 
auto& container = maudio [m_currentState] ; 
auto sound = container . find (l_id) ; 
if (sound == container . end ()) { return false; } 
sound- >second. second- >pause () ; 
sound- >second . first . m_manual Paused = true; 
return true; 

} 

Now it's time to move on from sound and to music, specifically how it can be played: 

bool SoundManager :: PlayMusic (const std :: strings l_musicld, 
float l_volume, bool l_loop) 

{ 

auto s = m_music . f ind (m_currentState) ; 

if (s == m_music . end ( ) ) { return false; } 

std::string path = m_audioManager- >GetPath ( l_musicld) ; 

if (path == ""){ return false; } 

if (! s- >second . second) { 

s->second. second = new sf::Music(); 

++m_numSounds ; 

} 

sf : : Music* music = s- >second . second; 

if (! music- >openFromFile (Utils :: GetWorkingDirectory ( ) + path) ) { 
delete music; 

- -m_numSounds ; 

s->second. second = nullptr; 

std: :cerr << "[SoundManager] Failed to load music from file: " 

<< l_musicld << std::endl; 
return false; 

} 

music- >setLoop (l_loop) ; 
music->setVolume (l_volume) ; 

music->setRelativeToListener (true) ; // Always relative. 
music->play () ; 

s - >second . first . m_name = l_musicld; 
return true; 

} 
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he actual audio 

file is then obtained by using our newly added GetPath method and checked for 
being blank. If it isn't, we check whether an actual instance of sf : : Music exists 
for the current state and create one if it doesn't. The openFromFile method of the 
sf : : Music instance is then called in an if statement in order to check if it was 
successful or not. If it wasn't, the sf : : Music instance is deleted and the number 
of sounds is decreased. Otherwise, the music instance is set to the volume and 
ng every 
to make music 

positional, we have no need for it at this point. 

Because we want the same functionality for music as we do for any given sound, 

11 : 

bool SoundManager :: PlayMusic (const StateType& l_state) { 
auto music = mmusic . f ind (m_currentState) ; 
if (music == m_music . end ( ) ) { return false; } 
if ( !music->second. second) { return false; } 
music->second. second- >play ( ) ; 
music- >second . first . m_manual Paused = false; 
return true; 

} 

bool SoundManager :: StopMusic (const StateType& l_state) { 
auto music = m_music . f ind (m_currentState) ; 
if (music == m_music . end ( ) ) { return false; } 
if ( !music->second. second) { return false; } 
music ->second. second- >stop ( ) ; 
delete music- >second . second; 
music- >second . second = nullptr; 

- -m_numSounds ; 
return true; 

} 

bool SoundManager :: PauseMusic ( const StateTypek l_state) { 
auto music = m_music . f ind (m_currentState) ; 
if (music == m_music . end ( ) ) { return false; } 
if (! music- >second . second) { return false; } 
music- >second. second- >pause () ; 
music- >second . first . m_manual Paused = true; 
return true; 

} 
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Let's get back to sound now. Since we're going to be utilizing its spatial qualities, it's 
n space: 

bool SoundManager :: SetPosition (const SoundID& l_id, 
const sf : : Vector3f & l_pos) 

{ 

auto& container = m_audio [m_currentState] ; 
auto sound = container . find (l_id) ; 
if (sound == container . end ()) { return false; } 
sound- >second. second- >set Posit ion (l_pos) ; 
return true; 

} 

This method simply locates the sound instance in its container and sets its position 
to the one provided as an argument. 

what the 

I sPlaying method is for: 

bool SoundManager :: IsPlaying (const SoundID& l_id) { 
auto& container = maudio [m_currentState] ; 
auto sound = container . find (l_id) ; 
return (sound != container . end ( ) ? 

sound- >second. second- >getStatus ( ) : false); 

} 

be forced into 
the status 

as a Boolean works just fine. 

Next, we have a way for obtaining the sound properties: 

SoundProps* SoundManager: : GetSoundProperties ( 
const std: : strings l_soundName) 

{ 

auto& properties = m_properties . f ind (l_soundName) ; 
if (properties == m_properties . end ( ) ) { 

if ( ! LoadProperties (l_soundName) ) { return nullptr; } 
properties = m_properties . f ind (l_soundName) ; 

} 

return ^properties- >second; 

} 
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Because sound properties aren't loaded during start-up, simply not finding the 
the case, 

the LoadProperties method is invoked. It returns a Boolean value that informs us 
of a failure, in which case a nullptr value is returned. Otherwise, the properties 
hod. 

k at how 

they're loaded from the . sound file: 

bool SoundManager :: LoadProperties (const std::string& l_name) { 
std: : if stream file; 

file . open (Utils : : GetWorkingDirectory ( ) + 

"media/Sounds/" + l_name + ".sound"); 
if ( ! f ile . is_open ( ) ) { 

std: :cerr << "Failed to load sound: " << l_name << std::endl; 
return false; 

} 

SoundProps props ( " " ) ; 
std::string line; 

while ( std :: getline ( file , line) ) { 
if (line[0] == 1 | 1 ) { continue; } 
std: : stringstream keystream ( line) ; 
std:: string type; 
keystream >> type; 
if (type == "Audio") { 

keystream >> props . m_audioName ; 

} else if (type == "Volume") { 
keystream >> props . m_volume ; 

} else if (type == "Pitch") { 
keystream >> props .m_pitch; 

} else if (type == "Distance")! 

keystream >> props . m_minDistance ; 

} else if (type == "Attenuation")! 

keystream >> props .m_attenuation; 

} else { 

// ? 

} 

} 

file . close ( ) ; 

if (props . m_audioName == ""){ return false; } 
m_properties . emplace ( l_name , props) ; 
return true; 

} 
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Having loaded many files in the past, this should be nothing new. So, let's just breeze 
right through it. A temporary SoundProps instance called props is created on the 
stack with a default audio name that is blank. The file is then processed and checked 
tly into the 

temporary properties instance using the >> operator. 

„\* For extra credit, the if else chain could be replaced with some sort of 

Cu tis 

VI for the sake of simplicity. 

Once the ties 
uring the 

process. If the name is, in fact, something other than a blank, the SoundProps 
r success. 

ing all 

sounds were introduced. Let's take a look at one of them now: 

void SoundManager :: PauseAll ( const StateTypek l_state) { 
auto& container = m_audio [l_state] ; 

for (auto itr = container . begin () ; itr != container . end ();) { 
if ( ! itr->second. second- >getStatus 0 ) { 

RecycleSound (itr->first, itr- >second . second, 
itr- >second . first . m_name) ; 
itr = container . erase ( itr ) ; 
continue ; 

} 

itr->second. second- >pause () ; 

++itr ; 

} 

auto music = m_music . f ind (l_state) ; 
if (music == m_music . end ( ) ) { return; } 
if (! music- >second . second) { return; } 
music- >second. second- >pause () ; 

} 

The PauseAll method first obtains the container of all sounds for the provided state, 
not. If it is, the 

sound is simply recycled and the element is erased. Otherwise, the sound's pause 
method is called. Music for the provided state is also paused, provided that it exists. 
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The UnpauseAll method is simpler, as it has no reason to recycle sounds: 

void SoundManager :: UnpauseAll ( const StateTypek l_state) { 
auto& container = maudio [l_state] ; 
for (auto &itr : container) { 

if ( itr . second . first . m_manualPaused) { continue; } 
itr . second . second- >play ( ) ; 

} 


auto music = m_music . f ind (l_state) ; 
if (music == m_music . end ( ) ) { return; } 

if (! music- >second . second | | music- >second . first . m_manualPaused) { 
return; 

} 

music- >second. second- >play ( ) ; 

} 

The catch here is that the sounds and music are only played again if they weren't 
manually paused by their respective Pause methods. 

t is 

responsible for actual creation and recycling of the sf : : Sound instances: 

sf::Sound* SoundManager :: CreateSound (SoundID& l_id, 
const std :: strings l_audioName) 

{ 

sf::Sound* sound = nullptr; 

if (! m_recycled . empty ( ) && (m_numSounds >= Max_Sounds | 
mrecycled . size ( ) >= Sound_Cache) ) 

{ 

auto itr = m_recycled . begin () ; 
while (itr != mrecycled . end ( ) ) { 

if ( itr- >first . second == l_audioName) { break; } 

+ + i t r ; 

} 

if (itr == m_recycled . end ( ) ) { 

// If a sound with the same name hasn't been found! 
auto element = m_recycled . begin () ; 
l_id = element- >first . first ; 

m_audioManager- >ReleaseRe source (element- >f irst . second) ; 
m_audioManager- >RequireResource (l_audioName) ; 
sound = element ->second; 

sound- >setBuffer ( *m_audioManager- >GetResource ( l_audioName) ) ; 
m_recycled . erase (element) ; 

} else { 
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l_id = itr- >first . first ; 
sound = itr->second; 
m_recycled . erase ( itr ) ; 


return sound; 


if (m_numSounds < Max_Sounds) { 

if (m_audioManager- >RequireResource ( l_audioName) ) { 
sound = new sf::Sound(); 
l_id = m_lastID; 

++m_lastID ; 

++m_numSounds ; 

sound- >setBuffer ( *m_audioManager- >GetResource ( l_audioName) ) ; 
return sound; 


std::cerr << " [SoundManager] Failed to create sound." 

<< std : : endl ; 
return nullptr; 

} 


A local variable named sound is first set up with the value of nullptr, and it will 
be manipulated throughout the rest of this method. The size of the recycled sound 
ds 

overall or maximum cached sounds has been exceeded, 
tainer 

isn't empty, we know we're going to be recycling an already existing sound. This 
process begins by first attempting to find a sound that already uses the same 
sf : : SoundBuf fer instance. In the case of such sound not existing, we simply pop 
the first element from the recycled container, store its ID in the variable l id and 
release the resource that was used by the sound being recycled. The l_id argument 
takes a reference to a SoundiD that it modifies, which serves as a way to let the 
he new 

resource that our sound is going to use is then reserved and our sound variable is set 
sound buffer. 

Our refurbished sound is removed from the recycled container. On the other hand, 
if a sound that uses the same sf : : SoundBuf fer instance was found, it doesn't need 
red and it's 

erased from the m_recycled container. 
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e, a new 

sound is created instead of using a recycled one. The ID of the sound is set to match 
that of m_lastlD, which is then incremented (same as m_numSounds). After the 
ng, such as 

in the SetUpSound method: 

void SoundManager :: SetUpSound ( sf :: Sound* l_snd, 

const SoundProps* l_props, bool& l_loop, bool& l_relative) 

{ 

l_snd->setVolume ( l_props- >m_volume) ; 
l_snd->setPitch (l_props->m_pitch) ; 
l_snd- >setMinDistance (1 props->m minDistance) ; 
l_snd- >setAttenuation (l_props->m_attenuation) ; 
l_snd->setLoop (l_loop) ; 

l_snd- >setRelativeToListener (l_relative) ; 

} 

The main idea of this method is simply reducing code wherever possible. It sets up 
y of the 

sound all based on the arguments provided. 

Let's wrap this class up with a relatively simple yet commonly used piece of code: 

void SoundManager :: RecycleSound ( const SoundID& l_id, 
sf::Sound* l_snd, const std : : strings l_name) 

{ 

m_recycled . emplace_back (std : : make_pair ( l_id, l_name) , l_snd) ; 

} 

This method is only responsible for pushing the information provided as arguments 
into the recycled container for later use. 

Adding support for sound 

In order to make our entities emit sounds, some preparations have to be made. 

und 

fication 

of the EntityMessage enumeration in EntityMessages .h: 
enum class EntityMessage { 

Move, Is_Moving, FrameChange , State_Changed, Direction Changed, 
Switch_State , Attack_Action, Dead 

} ; 
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The highlighted bits are what we're going to be focusing on. Frame_Change is a new 
type of message that's been added in this chapter, and Direct ion_Changed will be 
en a frame 
ke a few 

more adjustments to our code base. 

Animation system hooks 

In order to have the ability to send out the Frame_Change message we've just 
created, our animation system is going to need a few minor additions, starting 
with Anim_Base . h: 

class Anim_Base{ 
public : 

bool CheckMoved () ; 
protected: 

bool m_hasMoved; 


} ; 


t frame 

of an animation has recently been changed. Let's actually integrate this code in 
Anim_Base . cpp: 

Anim_Base : :Anim_Base() . . . , m_hasMoved (false) { ... } 

bool Anim_Base : : CheckMoved ( ) { 
bool result = m_hasMoved; 
m_hasMoved = false; 
return result; 

} 

In the constructor, it's important to remember to set the newly added data member to 
a default value, which in this case is false. The actual CheckMoved method is a very 
basic chunk of code that returns the value of m_hasMoved but sets it to false at the 
same time in order to avoid false positives. 
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Now that we have an active flag that is going to be used to check for frame changes, 
all that's missing is simply setting it to true in the SetFrame method: 

bool Anim_Base :: SetFrame (const unsigned int& l_frame) { 

if ( (l_frame >= m_frameStart && l_frame <= m_frameEnd) | | 

(l_frame >= m_frameEnd && l_frame <= m_f rameStart ) ) 

{ 

m_f rameCurrent = l_frame; 

m hasMoved = true; 
return true; 

} 

return false; 

} 

Notice the return value is now a Boolean instead of void. This additional change 
ing our 

last alteration in Anim_Directional . cpp: 

void Anim_Directional ; : FrameStep ( ) { 
bool b = SetFrame (m_f rameCurrent + 

(m_f rameStart <= m_frameEnd ? 1 : -1) ) ; 
if (b) { return; } 

if (m_loop) { SetFrame (m_f rameStart) ; } 
else { SetFrame (m_frameEnd) ; Pause ( ) ; } 

} 

rementing 

the current frame by hand by using m_f rameCurrent to only using the SetFrame 
method. 

Entity component system expansion 

the puzzle in making this work by sending out the Frame_Change message 
in S_Sheet Animat ion . cpp: 

void S_SheetAnimation :: Update ( float l_dT) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for(auto kentity : m_entities) { 

if ( sheet - >GetSpriteSheet ( ) - >GetCurrentAnim ( ) - >CheckMoved ( ) ) { 
int frame = sheet - >GetSpriteSheet ()- > 

GetCurrentAnim ( ) - >GetFrame ( ) ; 

Message msg ( (MessageType) EntityMessage : : Frame_Change) ; 
msg . m receiver = entity; 
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msg . m_int = f r ame ; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

} 



The Update method, as you might recall, already handles other types of messages 
that are related to entities attacking and dying, so this is already gift-wrapped for us. 
The CheckMoved method we added earlier comes in handy and aids us in checking 
nd stored in 

the message, which is shortly followed by a Dispatch call. 

The sound emitter component 

Within the entity component system paradigm, every possible entity parameter or 
feature is represented as a component. Emitting sounds is definitely one of those 
starting 

with creating and implementing it in the c_SoundEmitter . h header. Before that, 
however, let's define the types of sounds an entity can have: 

enum class EntitySound{ None = -1, Footstep, Attack, Hurt, Death }; 

one of 

which is going to be implemented in this chapter. A None value is also set up in 
order to make error checking easier. 

es it plays 
rmation: 

struct SoundParameters{ 

static const int Max_SoundFrames = 5; 

SoundParameters () { 

for (int i = 0 ; i < Max_SoundFrames ; ++i) { m_frames [i] = -1; } 

} 

std::string m_sound; 

std : : arraycint , Max_SoundFrames> m_frames; 

} ; 


Since sounds are going to be tied to specific frames of animation, we need to define 
hem. 

The static constant named Max_SoundFrames is used for that purpose here. 
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The constructor of the SoundParameters structure initializes the entire array of 
tion in a 

slightly more efficient way, as the check can be over whenever the first -1 value is 
so stores 

the name of the sound that is to be emitted. 

Now, we can finally begin implementing the sound emitter component: 

class C_SoundEmitter : public C_Base{ 
public : 

static const int Max_EntitySounds = 4; 


private : 

SoundID m_soundID; 

std : : array<SoundParameters , Max_EntitySounds> m_params; 

} ; 


of entity 
embers. 

The finot be 

played repeatedly and have to wait until the previous sound is finished. The second 
data member is an array of sound parameters for each possible type of entity sound. 

Let's begin implementing the component, starting with its constructor: 

C_SoundEmitter ( ) : C_Base (Component : : SoundEmitter ) , m_soundID ( -1 ) {} 

Apart from the typical invocation of the c_Base constructor with the component 
signify 

that this component currently is not playing any sounds, 
going 


const std : : strings GetSound ( const EntitySoundk l_snd) { 
static std:: string empty = 
return (( int ) l_snd < Max_EntitySounds ? 
m_params [ (int) l_snd] .m_sound : empty) ; 

} 

By simply providing one of the enumerated values of EntitySound as an argument, 
outside classes can retrieve information about which sound to play given the 
circumstances. 
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ound system 
ting sound 

or not. This is where the isSoundFrame method comes in: 

bool IsSoundFrame ( const EntitySoundk l_snd, int l_frame) { 
if ((int)l_snd >= Max_EntitySounds) { return false; } 
for (int i = 0; i < SoundParameters : : Max_SoundFrames ; ++i) { 
if (m params [ ( int ) 1 snd] ,m_frames [i] == -1) { return false; } 
if (m params [ (int) 1 snd] .m frames [i] == l_frame) {return true;} 

} 

return false; 

} 

ty sound 
ID, falseted 

over. If a -1 value is encountered, false is returned right away. However, if the 
frame provided as an argument matches a sound frame in the array, this method 
returns true. 

formation: 

SoundID GetSoundID ( ) { return m_soundID; } 

void SetSoundID ( const SoundID& l_id) { m_soundID = l_id; } 
SoundParameters* GetParameters ( ) { return &m_params [0] ; } 

file, 

let's take a gander at what it might look like. This snippet can be found inside 
Player . entity: 

Name Player 

Component 6 footstep: 1,4 

nd effect to 

be played, followed by a set of frames delimited by commas. The name of the sound 
his: 


void Readln ( std : : stringstream& l_stream) { 
std: : string main_delimiter = 
std::string f rame_delimiter = 
for (int i = 0; i < Max_EntitySounds ; ++i) { 
std::string chunk; 
l_stream >> chunk; 
if (chunk == ""){ break; } 
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std: : string sound = chunk . substr ( 0 , 
chunk . find (main_delimiter) ) ; 
std::string frames = chunk . substr ( 

chunk . find (main_delimiter) + main_delimiter . length ()) ; 
m_params [i] .m_sound = sound; 
size_t pos = 0; 
unsigned int frameNum = 0; 

while (frameNum < SoundParameters : : Max_SoundFrames ) { 
pos = frames . find (frame_delimiter) ; 
int frame = -1; 

if (pos != std: :string: :npos) { 

frame = stoi ( frames . substr ( 0 , pos)); 
f rames . erase ( 0 , pos + f rame_delimiter . length ()) ; 

} else { 

frame = stoi ( frames ) ; 

m_params [i] . m frames [frameNum] = frame; 
break ; 

} 

m params [i] ,m_f rames [frameNum] = frame; 

++ frameNum; 

} 

} 


ible entity 
ring named 

chunk. If that string is actually empty, we break out of the loop as there's clearly no 
rts right at 

the colon delimiter: sound and frames. The entity sound is then stored inside the 
parameters structure. 

Lastly, it's necessary to process the frame information, which is delimited by commas. 
Two local variables are set up to help us with this: pos that stores the position of 
the comma delimiter if one is found and frameNum that is used to make sure the 
Max_SoundFrames limit is honored. Inside the while loop, the frame delimiter is first 
located using the find method of the std : : string class. If a delimiter was found, 
the frame is extracted from the string and converted to an integer, which is stored 
inside the variable frame. That entire segment, including the delimiter, is then erased 
from the string frames and the extracted information is stored inside the parameters 
structure. In a case where a delimiter wasn't found, however, the loop is stopped right 
after the frame information has been extracted. 
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The sound listener component 

r within our 
tely, there 
omponent 

for an audio listener: 

class C_SoundListener : public C_Base{ 
public : 

C_SoundListener ( ) : C_Base (Component :: SoundListener ) { } 

void Readln ( std : : stringstream& l_stream) { } 
private : 


} ; 


Yes, that's it! In its most essential form, this class simply represents a sign that its 
owner entity should be treated as a listener in the auditory world. 

Implementing the sound system 

have a 

green light to begin implementing the sound system that is going to bring all of this 
code to life. Let's get it started! 

class S_Sound : public S_Base{ 
public : 

S_Sound (SystemManager* l_systemMgr) ; 

~S_Sound ( ) ; 

void Update (float l_dT) ; 

void HandleEvent (const Entityldk l_entity, 
const EntityEventk l_event) ; 
void Notify(const Messages^ l_message) ; 

void Setup (AudioManager* l_audioManager , 

SoundManager* l_soundManager) ; 
private : 

sf::Vector3f MakeSoundPosition (const sf : : Vector2f & l_entityPos, 
unsigned int l_elevation) ; 
void EmitSound (const Entityld& l_entity, 

const EntitySoundk l_sound, bool l_useld, bool l_relative, 
int l_checkFrame = -1) ; 

AudioManager* m_audioManager ; 

SoundManager* m_soundManager ; 

} ; 
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d a 
f the 

AudioManager and SoundManager classes. Let's begin actually implementing 
the sound system: 

S_Sound: : S_Sound (SystemManager* l_systemMgr) 

: S_Base (System: : Sound, l_systemMgr) , m_audioManager (nullptr ) , 
m_soundManager (nullptr) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : Position) ; 
req . TurnOnBit ( (unsigned int ) Component : : SoundEmitter ) ; 
m_requiredComponents .push_back (req) ; 

req . ClearBit ( (unsigned int) Component : : SoundEmitter ) ; 
req . TurnOnBit ( (unsigned int ) Component : : SoundListener ) ; 
m_requiredComponents .push_back (req) ; 

m_systemManager- >GetMessageHandler ( ) - > 

Subscribe (EntityMessage : : Direction_Changed, this) ; 
m_systemManager- >GetMessageHandler ( ) - > 

Subscribe (EntityMessage : : Frame_Change , this) ; 

} 

e 

usly. 

ager, 

a method like this can definitely come in handy: 

void S_Sound :: Setup (AudioManager* l_audioManager , 

SoundManager* l_soundManager) 

{ 

m_audioManager = l_audioManager ; 
m_soundManager = l_soundManager ; 

} 

Next, let's take a jab at implementing the Update method: 

void S_Sound :: Update ( float l_dT) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for (auto &entity : m_entities) { 

C_Position* c pos = entities- > 

GetComponent<C_Position> (entity, Component: : Position) ; 
sf::Vector2f position = c_pos->GetPosition ( ) ; 
unsigned int elevation = c_pos- >GetElevation ( ) ; 
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bool IsListener = entities-> 

HasComponent (entity, Component: : SoundListener ) ; 
if (IsListener) { 

sf : : Listener : : setPosition ( 

MakeSoundPosition (position, elevation) ) ; 

} 


if (! entities - >HasComponent ( 

entity. Component: : SoundEmitter ) ) 

{ 

continue ; 

} 

C_SoundEmitter* c_snd = entities- >GetComponent<C_SoundEmitter> 
(entity , Component : : SoundEmitter ) ; 
if (c_snd- >GetSoundID ( ) == -1) { continue; } 
if ( ! IsListener) { 

if ( ! m_soundManager- >SetPosition (c_snd- >GetSoundID ( ) , 
MakeSoundPosition (position, elevation) ) ) 

{ 

c_snd- >SetSoundID ( - 1 ) ; 

} 

} else { 

if ( ! m_soundManager- >IsPlaying (c_snd- >GetSoundID ( ) ) ) { 
c_snd- >SetSoundID ( - 1 ) ; 



Each entity in this system first has its position and elevation obtained and stored 
s the sound 

listener or not and stores that information inside a Boolean variable. 

not equal 
d. If the current 
n and catch 

the result of that in an i f statement. If the position update fails, the sound ID is 
ity is, in fact, a 
we determine 

if the sound is still playing or not by calling the I sPlaying method. 
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Afterwards, it's necessary to update the position of the sf : : Listener class if the 
current entity has the listener component. Note the use of the MakeSoundPosition 
method here, as well as in the previous chunk of code. It returns a sf : : Vector3f 
his method 
shortly. 

sly next: 

void S_Sound : :Notify (const Messaged l_message) { 
if ( ! HasEntity ( l_message . m_receiver ) ) { return; } 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
bool IsListener = entities-> 

HasComponent (l_message .m_receiver, Component: : SoundListener ) ; 
EntityMessage m = (EntityMessage) l_message .m_type; 
switch (m) { 

case EntityMessage: : Direction_Changed : 

{ 

if (! IsListener ) { return; } 

Direction dir = (Direction) l_message . m_int ; 
switch (dir) { 

case Direction :: Up : sf :: Listener :: setDirection ( 0 , 0, -1); 
break ; 

case Direction :: Down : sf :: Listener :: setDirection ( 0 , 0, 1); 
break ; 

case Direction :: Left : sf :: Listener :: setDirection ( -1 , 0, 0); 
break ; 

case Direction :: Right : sf :: Listener :: setDirection ( 1 , 0, 0) ; 
break ; 

} 

} 

break ; 

case EntityMessage: : Frame_Change : 

if ( ! entities - >HasComponent ( l_message . m_receiver , 

Component : : SoundEmitter ) ) 

{ 

return; 

} 

EntityState state = entities- >GetComponent<C_State> 

(l_raessage.m_receiver, Component: : State) ->GetState() ; 
EntitySound sound = EntitySound :: None ; 

if (state==EntityState : :Walking) { sound=EntitySound : : Footstep;} 
else if (state == EntityState :: Attacking) { 
sound = EntitySound :: Attack; 

} else if (state==EntityState : : Hurt) { sound=EntitySound : : Hurt; } 
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else if ( state==EntityState :: Dying) { sound=EntitySound :: Death; } 
if (sound == EntitySound : : None) { return; } 

EmitSound ( l_message . m_receiver , sound, false, 

IsListener, l_message . m_int ) ; 
break ; 



we obviously 

need to change the direction of the sf : : Listener to match the one that is carried 
rame 

changing, the EmitSound method is called with the entity ID, sound type, two 
Boolean flags indicating whether the sound should loop and whether it should be 
in all passed 
mply decided 

by whether the current entity itself is a listener or not. 

Positioning sounds in space is also a huge part of this whole system working 
correctly. Let's take a look at the MakeSoundPosition method: 

sf : :Vector3f S_Sound: : MakeSoundPosition ( 

const sf : : Vector2f & l_entityPos, unsigned int l_elevation) 

{ 

return sf::Vector3f( l_enti tyPos . x, 

l_elevation * Sheet :: Tile_Size , l_entityPos . y) ; 

} 

Due to the default up vector in SFML being the positive Y axis, the two dimensional 
coordinates of an entity position are passed in as X and Z arguments. Meanwhile, the 
Y argument is simply the entity's elevation multiplied by the Tile_size value, found 
inside the Map . h header, which results in entity elevation simulating the height. 

Last but defies 

emitting all their sounds that we need to take a look at: 

void S_Sound :: EmitSound ( const Entityld& l_entity, 

const EntitySound& l_sound, bool l_useld, bool l_relative, 
int l_checkFrame) 

{ 

if ( ! HasEntity ( l_entity) ) { return; } 

if ( ! m_systemManager- >GetEntityManager ( ) -> 

HasComponent (l_entity, Component: : SoundEmitter ) ) 

{ 

return; 

} 
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// Is a sound emitter. 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
C_SoundEmitter* c_snd = entities- >GetComponent<C_SoundEmitter> 
(l_entity, Component: : SoundEmitter) ; 
if ( c_snd- >GetSoundID ( ) != -1 && l_useld) { return; } 

// If sound is free or use of ID isn't required, 
if (l_checkFrame != -1 && 

! c_snd- >IsSoundFrame ( l_sound, l_checkFrame) ) 

{ 

return; 

} 

// Frame is irrelevant or correct. 

C_Position* c_pos = entities- > 

GetComponent<C_Position> ( l_entity , Component: : Position) ; 
sf::Vector3f pos = (l_relative ? 
sf : :Vector3f (0 . f , O.f, O.f) : 

MakeSoundPosition ( c_pos - >GetPosition ( ) , 
c_pos->GetElevation() ) ) ; 
if (l_useld) { 

c_snd- >SetSoundID (m_soundManager- > 

Play (c_snd- >GetSound (l_sound) , pos) ) ; 

} else { 

m_soundManager- >Play (c_snd- >Get Sound ( l_sound) , 
pos, false, l_relative) ; 

} 

} 

The first task is obviously checking if the sound system has an entity with the 
mitter component 

is obtained and the sound ID it stores is checked for being equal to -1. The code still 
e l_useld 

argument is set to false, which tells us that a sound should be emitted regardless, 
al to -1, 

which means the sound should be played regardless, or for it being one of the 
sound frames defined inside the sound emitter component. 

obtained 

e to the listener, 

axes. 
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If we want to only keep a single instance of a particular sound, the Play method of 
the sound manager is invoked within the SetSoundlD argument list of the sound 
ssed in, 

as the other two Boolean flags hold the default values of false. Otherwise, if this 
already 

emitting another sound or not, the Play method of our sound manager is called 
by itself and the Boolean flag for sound being relative to the listener is passed in 
as the last argument. 

Integrating our code 

In order to prevent sounds or music from playing at inappropriate times, our state 
manager must notify the sound manager of any state changes: 

void StateManager :: SwitchTo (const StateTypek l_type) { 
m_shared- >m_soundManager- >ChangeState (l_type) ; 


} 

1 it when 
that happens: 

void StateManager :: RemoveState (const StateType& l_type) { 
for (auto itr = m_states . begin () ; 
itr != m_states . end ( ) ; + + itr) 

{ 

if (itr->first == l_type) { 

m_shared- >m_soundManager- >RemoveState (l_type) ; 
return; 

} 

} 

} 

The only thing we have left to do now is actually integrating everything we worked 
on into the rest of our code base, starting with SharedContext . h: 


#include "AudioManager . h" 
#include "SoundManager . h" 

struct SharedContext { 
SharedContext () : 
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m_audioManager (nullptr) , 
m_soundManager (nullptr) , 

{} 


AudioManager* m_audioManager ; 
SoundManager* m_soundManager ; 


} ; 


Next, instantiating and managing these two new classes inside the shared context 
is of utmost importance. Let's start by modifying the Game . h header: 

class Game{ 
public : 

private : 

AudioManager m_audioManager ; 

SoundManager m_soundManager ; 


} ; 


As always, we keep these manager classes inside Game in order to manage their 
gh. They 

require to be set up like this: 

Game: :Game() : . . . , m_soundManager ( &m_audioManager ) 

{ 


m_context . m_audioManager = &m_audioManager ; 
m_context . m_soundManager = &m_soundManager ; 

m_systemManager . GetSystem<S_Sound> (System : : Sound) -> 
Setup (&m_audioManager, &m_soundManager ) ; 


} 

After both classes are created, their addresses are passed to the shared context. One 
sound system 
anager. 
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Let's not forget to also update the sound manager properly during the flow of the 
entire application: 

void Game : : Update ( ) { 

m_soundManager . Update (m_elapsed . asSeconds () ) ; 

} 

With the creation of new components and systems comes the responsibility of 
making sure they can actually be created automatically, by adding the component 
types to the entity manager: 

EntityManager : : EntityManager (SystemManager* l_sysMgr, 

TextureManager* l_textureMgr) : ... 

{ 

AddComponentType<C_SoundEmitter> (Component : : SoundEmitter ) ; 
AddComponentType<C_SoundListener> (Component : : SoundListener ) ; 

} 

Our sound system also needs to be created inside the system manager: 
SystemManager: : SystemManager ( ) : . . . { 

m_systems [System :: Sound] = new S_Sound (this) ; 

} 

Having all of that done, we can finally add some music to our game! Let's start by 
making sure we have an intro soundtrack by modifying state_lntro . cpp: 

void State_Intro : : OnCreate ( ) { 

m_stateMgr- >GetContext ( ) - >m_soundManager- > 

PlayMusic ( "Electrix" , 100. f, true); 

} 

Also, it would be nice to have some background music during actual game-play, so 
let's modify state_Game . cpp as follows: 

void State_Game :: OnCreate () { 

m_stateMgr- >GetContext ( ) - >m_soundManager- > 

PlayMusic ( "TownTheme" , 50. f, true); 

} 

And voila! Just like that, we now have music and dynamic sound effects baked into 
our RPG! 
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Summary 

cal 

scores tugging at the heart strings of the player, our game world starts to develop a 
sense of character and presence. All of the hard work we put in towards making sure 
n of quality, 
ters 

remaining, the most challenging part is still yet to come. 

In the next chapter, we will be exploring the vast world of networking and how it 
can help us turn our lonely, quiet RPG into a battle zone of multiple other players. 
See you there! 
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g games 
mongst 

many groups. Expressions such as "frag" or "camping" became buzzwords amongst 
ine game, 

networking obviously plays a huge role in the gaming circles. Introducing the 
element of other human players amplifies the content added, on top of making the 
game's universe seem much more alive and flourishing. In many instances, this 
njoyable 
essence of 

multiplayer, and perhaps even propagate the six degrees of separation. 

In this chapter, we're going to be covering: 

• Fundamentals of networking applications 

• Utilizing threads and ensuring data safety 

• Implementing our own basic communication protocol 

• Building a simple chat client and server 

or Id! 


[ 391 ] 



We Have Contact! - Networking Basics 


Basics of networking 

First things first, let's cover a term that is pretty much synonymous with networking 
at this point: sockets. What is a socket? In its simplest terms, a socket is just an 
are 

etween 

them. When data is sent from application A to application B, it first leaves from the 
reaches the 

socket of application B: 


Application B 

©01101001010 © 


Application A 



Data 



nbe 
rposes 
ort is just a 
5. While 

a service is using a specific port, another socket cannot bind to it until it's freed. The 
most commonly used ports are in a range of 20-1024. For example, port 80 is always 
used for HTTP traffic, which is what most website hosting servers operate on. 

SFML networking 

In order to access network constructs in SFML, we must first include the 
network header: 

#include <SFML/Network . hpp> 

ibrary files in 

order to link properly, specifically sfml-network . lib, ws2_32 . lib, and winmm. lib. 
operly. 

There are several types of sockets available out there, each with specific features, 
advantages, and disadvantages. SFML provides us with two basic types: TCP and 
UDP. TCP stands for Transmission Control Protocol, while UDP stands for User 
Datagram Protocol. Both of these protocols are capable of sending and receiving 
data, but they are fundamentally different from each other under the hood. It's fair 
me port, 

it can still be bound to by two different protocols. 
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TCP sockets 

TCP is a connection-based protocol, which means that before data can be exchanged, 
a connection has to be established by having an application that attempts to initiate 
it (a client) connect to another application that is actively waiting for connections 
attempt: 

sf : : TcpSocket socket; 
sf Socket :: Status status = 

socket . connect (" 192 . 168 . 1 . 2 " , 5600, sf :: seconds ( 5 . f )) ; 
if (status != sf Socket : :Done) { 

// Connection failed. 

} 

First, we create a TCP socket instance. Its connect method is called next, with three 
arguments: 

• The first argument is of the type sf : : ipAddress and is exactly what it 

open and have a server accepting connections. 

• The second argument is the port number. 

• Lastly, we have the third argument, which is completely optional. It's the 
If 

e 

is used. 

The return value of the connect method is captured and stored in a 
sf : : Socket : : Status type, which is just an enumeration table that has a few useful 
values, such as Done, NotReady, Partial, Disconnected, and Error. Every method 
ecting or 

disconnecting, returns a status that we can use for error checking. 

In order to accept a connection on the server side when using TCP, a special class 
is used: sf : : TcpListener. It has to be bound to a specific port and cannot send 
or receive any data: 

sf :: TcpListener listener; 

if (listener . listen (5600) != sf Socket : :Done) 

{ 

/ / Unable to bind to port . 

} 

sf :: TcpSocket incoming; 
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if (listener . accept ( incoming) != sf :: Socket :: Done) 

{ 

// Failed accepting an incoming connection. 

} 

After the socket is set up, the listener's accept method is called. Along with 
connectops 
s what's 

referred to as blocking. A good example of a blocking function from an STL library 
is std : : cin. Why is this important? Well, to put it simply, networking operations 
connection 

attempt may take, as the host on the other end could be unreachable. During that 
time, your application will stand still and do absolutely nothing. 

After a connection finally comes through, the incoming socket can be used to 
communicate with the client: 

char data [100] ; 

II ... 

if (socket . send (data, 100) != sf :: Socket :: Done) { 

// Sending data failed. 

} 

The send method has two variations: a low-level one that allows the user to send a 
we're going to 

be covering shortly. The low-level version takes in a void pointer and the number of 
bytes it should send. 


Make sure to always check the returned status for errors! 

In order to receive data on the other end, a socket needs to listen: 

char data [100]; 
std::size_t received; 

if (socket . receive (data, 100, received) != sf :: Socket : :Done) 

{ 

// Failed receiving data. 

} 
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the 

maximum size it can contain, which is the second argument of the receive method, 
r when data 

comes in. The receive method is also blocking by default. This means that it will halt 
the entire program until some data comes through. 

Handling multiple connections 

Youone 
t is almost 
sockets at 
the same time: 

sf : : TcpSocket socket; 

II ... 

sf : : SocketSelector selector; 
selector . add (socket ) ; 

The sf : : SocketSelector class provides a way for us to block on multiple sockets, 
for incoming 


A very important thing to keep in mind is that the socket selector does 
his 
be 

stored in a data container of your choosing. 

To handle incoming data from multiple sockets, the wait method of a socket selector 
class is used: 

sf :: SocketSelector selector; 

std : :vector<sf : :TcpSocket> container; 

II ... 

sf :: TcpSocket socket; 
selector . add (socket ) ; 
container . push_back (socket ) ; 
if (selector .wait (sf : :seconds (10) ) ) { 
for (auto &itr : container) { 
if (selector . isReady ( itr) ) { 

// Socket received data, 
char data [100] ; 
std::size_t received; 

sf :: Socket :: Status status= itr . receive (data, 100, received); 
if (status != sf : ;Socket : :Done) { 
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// Failed receiving data... 

} 

} 

} 

} else { 

/ / Timed out . . . 

} 

The argument provided in the wait method is, once again, optional. If one of 
the socket inside the selector receives something, true is returned and we can 
iterate over our data container to find the socket that received data, by using 
the isReady method. 

TCP protocol specifics 

One major difference between TCP and UDP is transmission reliability. The 
TCP protocol uses something called a three-way -handshake when establishing 
a connection. It looks a little something like this: 


Clien 

t Server 




1 = 



v ... 

-• 1 ACK 1 ► 




A SYN (synchronize) packet is first sent by the party attempting to establish a 
connection. The server responds with a SYN/ACK (synchronize-acknowledgement) 
packet, to which the client responds with an ACK (acknowledgement) packet. These 
three exchanges of data happen at the beginning of every connection. Afterwards, 
which the 

receiving party always replies with an ACK packet. If the party sending some data 
does not receive an ACK response, the same data is sent again after a specific time 
a sequence 
in order, 
waiting if some 

data got lost somewhere and additional data overhead, TCP ends up being slower 
and bulkier. If a packet gets lost somewhere, the receiving party has to wait until 
ns and even 
some really 

fast-paced games that require highest possible efficiency and don't care about packet 
loss end up using UDP. 
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User datagram protocol 

Both TCP and UDP sockets in SFML actually inherit from the same base class, 

. One major 

difference, however, is that UDP is connectionless. This means that there is no such 

gement 

hecks, no 

t out is 

reduces the 


the maximum 

size of the data being sent out. Data in UDP is being sent out in datagrams instead of 
streams, which is how TCP handles it. The maximum imposed datagram size, which 
is a little less than 65536 bytes, cannot be exceeded. 

Because UDP is connectionless, there is no equivalent of sf : : TcpListener that can 
be used to accept incoming traffic. The socket must be bound to a specific port before 
it can be used though: 

sf : :UdpSocket socket; 

// Bind to port 5600 

if (socket .bind (5600) != sf Socket : :Done) 

{ 

// Binding failed. 

} 


Binding to a random port is also possible, thanks to sf : : Socket : : AnyPort, which 
an be 

retrieved later like this: 


sf : ;UdpSocket socket; 

II ... 

unsigned int port = socket . getLocalPort ( ) ; 


e additional 
eceived from, 

on the count of UDP being connectionless: 


sf : :UdpSocket socket; 

II ... 

char data [100] ; 
if (socket . send (data, 
!= sf Socket Done) 

{ 


100, "192.168.1.2", 5600) 
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// Sending failed. 

} 

II ... 

sf : : IpAddress ipAddr; 
unsigned short port; 
std::size_t received; 

if (socket . receive (data, 100, received, ipAddr, port) 

!= sf Socket Done) 

{ 

// Receiving failed. 

} 

Lastly, UDP sockets do work with a sf : : SocketSelector class, but given the nature 
ause all 


Alternative to sending raw data 

Simply sending raw bytes across a network can get quite tricky, not to mention 
problematic. The first and perhaps the biggest issue is the endianness of a machine. 
Some processors interpret data in a different order than others. In a big-endian family, 
the most significant byte is stored first, while a little-endian family machine would 
do the opposite. Raw data being sent from a big-endian machine to a little-endian 
machine would be interpreted differently and result in funky results. 

On top of data being stored differently amongst all types of machines, the sizes 
ers. If 
to it not 
t and 
ed by 

the receivers. 

While all of this sounds fairly horrific, there are solutions to all of these problems. 
Data type size variations can be addressed by using SFML's fixed-size types, such as 
sf : : Int8, sf : :Uintl6, and so on. They are simple type definitions, mapped to data 
types that are sure to have the expected size depending on the platform. Exchanging 
these types over the network instead re-assures data safety. 
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SFML packets 

t to 

resolve. Enter sf : : Packet! It is a specialized, lightweight class that can be used to 
streams 

by using the << and >> operators for data insertion and extraction, as seen here: 

sf : : Inti 6 n = 16 ; 
float f = 32. f; 
std::string str = "Aloha"; 

sf:: Packet packet; 
packet << n << f << str; 

II ... 

packet >> n >> f >> str; 

While packing data is always guaranteed to work, extracting it can in fact fail. If it 
does, the packet error flag is set. Checking whether the flag is set or not is similar 
to testing a Boolean value, which is again similar to standard streams: 

if ( ! (packet >> n) ) { 

// Failed extraction. 

} 

Both TCP and UDP packets do provide overloaded send and receive methods that 
work with instances of sf : : Packet: 

sf:: Packet packet; 

// TCP 

tcpSocket . send (packet) ; 
tcpSocket . receive (packet) ; 

// UDP 

udpSocket . send (packet , "192.168.1.2", 5600); 

sf : : IpAddress senderIP; 
unsigned short senderPort; 

udpSocket . receive (packet , senderIP, senderPort); 

Custom data types can also be fed into or extracted from the sf : : Packet structure, if 
overloads of < < and > > operators are provided, as follows: 

struct SomeStructure{ 
sf::Int32 m_int ; 
std::string m_str; 

} ; 


sf:: Packets operator << (sf :: Packets l_packet, 
const SomeStructureS l_struct) 
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{ 

return l_packet << l_struct . m_int << l_struct . m_str ; 

} 

sf : : Packets operator >>( sf :: Packets l_packet, 

SomeStructureS l_struct) 

{ 

return l_packet >> l_struct . m_int >> l_struct . m_str ; 

} 

This enables easy insertion and extraction of a custom data type: 

SomeStructure s; 
sf:: Packet packet; 

packet << s; 
packet >> s; 

Using SFML packets with TCP sockets poses a small restriction. Due to the message 

. This 

inga 

SFML packet. UDP does not pose this restriction, as the protocol itself preserves 
message boundaries. 

Non-blocking sockets 

Both TCP and UDP sockets, as well as the TCP listener, are blocking by default. 
Their blocking mode can be changed to return immediately: 

sf : : TcpSocket tcp ; 

tcp . setBlocking (false) ; 

sf : : TcpListener tcpListener; 
tcpListener . setBlocking (false) ; 

sf : :UdpSocket udp; 
udp. setBlocking (false) ; 


n 

sf : : Socket : :NotReady, as well as trying to accept a TCP connection if there are 
way to 

not halt your program's execution by instead checking the availability of data or 
connections each time it is updated. 
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pass to 

it, even when using instances of sf : : Packet. If a sf : : Socket : : Partial status is 
returned, the data must be sent again at the exact byte offset of where the last call 
to send stopped. If raw data is sent, make sure to use this send overload: 

send(const void* data, std::size_t size, std::size_t& sent) 

It overwrites the third provided argument with the exact number of bytes sent out. 

Sending sf : : Packet instances does not require you to keep track of the byte offset, 
the packet 
filling it with 

the exact same data will not work, as the data offset that was stored internally inside 
the packet is lost. 


Letting the traffic flow 

There are a lot more subtleties to communicating over the internet than using the 
right code. As we discussed previously, the port number an application uses to send 
or receive data can be imagined as a gateway to your system, of which there are 
thousands. That gateway can either be open or closed. By default, it's more likely than 
not that whichever port you choose to use for your program is going to be closed on 
your system, which doesn't matter for local connections, but anything coming from 
the outside world through that particular port is not going to get through. Managing 
your ports can be done by visiting your router's settings page. The steps required to 
do so are different for each router out there. Luckily, http : //portf orward . com is 
there to help you! By visiting it and looking up the make and model of your router 
on this website, you can find detailed instructions on how any port can be opened 
or closed. 



Sockets bound to sf : : Socket : : AnyPort will most likely end up 
binding to a port in a range of 49152 and 65535. Port forwarding works 
for ranges, as well as individual ports. Opening this particular range 
of ports will ensure that your SFML networking application works as 
intended when communicating over the World Wide Web. 
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Firewalls also tend to block this type of traffic by default. For example, the Windows 
firewall prompts users about allowing traffic to come through for an application 
that's being launched for the first time. Depending on your application, however, 
that prompt may never manifest due to the Windows firewall not being the most 
reliable piece of software ever written. If all of your key ports are open and a 
particular program still doesn't seem to be sending or receiving anything, make sure 
to add your client or server program to the "allowed list" of the Windows firewall, by 
going to Control Panel, clicking on Windows Firewall, selecting Allow a program 
or feature through Windows Firewall on the left side, clicking Change settings, and 
finally hitting the Allow another program button. This will bring up another window 
that can be used to add your client/ server application by browsing for it and clicking 
on Add afterwards. 

Multi-threading 

Having blocking functions in your code can be a real nuisance. Listening for incoming 
network connections or data, asking users to input something into the console, or even 
loading game data, like textures, maps, or sounds, can block a program from executing 
until it's done. Have you ever wondered how certain games have a loading bar that 
actually moves while the data is being loaded? How can that be done with code that is 
executed sequentially? The answer to that is multi-threading. Your application runs all 
its code sequentially from top to bottom in something referred to as the main thread. 

It is not a program, as it can't exist by itself. Instead, a thread only runs within your 
application. The beauty of this is that multiple threads can exist and run all at once, 
which enables parallel code execution. Consider the following diagram: 


Application 

Thread #1 
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we do here is 
n addition 

to that. The first thread could be used to listen for incoming network connections. 
Thread #2 is responsible for loading/ unloading data when a new level is opened 
if all three 

threads are blocked, the application still keeps rendering! Neat! 
and 

control threads. Let's start by first giving a thread something to do: 

void Test ( ) { 

for (int i = 0; i < 10; ++i) { 

std : : cout << i << std::endl; 

} 

} 

the main 

thread. How can that be done? By using the sf : : Thread! 



C++ also provides its own thread class, std : : thread, as well its own 
locks and mutexes. It also provides a std : : future class template, 
which is useful when accessing results of asynchronous operations. 


First, it must be set up properly by providing a function or a member function 
pointer to its constructor: 

sf::Thread threadl (Test ) ; 

The thread constructor actually provides four overloads and even takes in the 
return value of std : : bind and lambda expressions, which allows us to provide 
t must be 

launched in order to execute the code: 

threadl . launch ( ) ; 

stopped. The 
sf : : ThreadSS 
local 

variables not being destroyed on some operating systems. Instead, your code should 
o longer 

needed. Terminating it by hand is not safe! You have been warned. 
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One last method that threads provide is the wait method: 
threadl . wait ( ) ; 


The thread it is called on will halt until threadl is finished. This could be potentially 
dangerous. In the case of an infinite loop or a blocking function being called in 
threadl that never unblocks, the program will hang completely. 



Never destroy an instance of sf : : Thread before it's done! This will 
wait method. Your application will be stuck. 


] 


Shared data protection 

Incidentally, the reason why threads are used is also the cause for most problems 
arallel is 

great, but what happens if two threads attempt to read or modify the same data? In 
lity. Imagine 
updated and 

rendered. So far, so good! Next, let's introduce a new thread that is going to be 
running network-specific code and has access to all of our entities. If this thread 
nee that it 

might happen during either the update or render cycle of the main thread. At this 
point, we all know too well what happens when an iterator you're using suddenly 
r code are 

thread-safe, by synchronizing them. 

SFML provides us with an interesting little class called sf : : Mutex. It stands for 
a single 
until it's done, 
this idea: 

sf : : Mutex mutex; 


void Test ( ) { 

mutex. lock ( ) ; 

for (int i = 0; i < 10; ++i){ 

std ; : cout << i << std::endl; 

} 

mutex . unlock ( ) ; 

} 
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int main ( ) { 

sf::Thread threadl (Test ) ; 
threadl . launch ( ) ; 

mutex . lock ( ) ; 

// Do something data- sensitive here, 
mutex . unlock ( ) ; 
return 0 ; 

} 


The mutex class provides us with two methods: lock and unlock. When a mutex 
is locked for the first time, the thread that locked it is given priority and is allowed 
to continue executing the code. If another thread calls the lock method of the same 
1 the mutex is 

unlocked. Once it is, the waiting is over and the second thread is allowed to continue. 

Let's analyze what happens in the code example above: threadl is bound to the 
Testd 

because it hasn't been locked yet, the loop for printing numbers begins iterating. In 
the meantime, our main thread reaches the mutex, lock ( ) ; line. A few numbers may 
have been printed out already by this point. Because the mutex is already locked, the 
main thread halts immediately. Once the last number of the Test function is printed 
out, the mutex . unlock ( ) ; line is reached. This enables the main thread to lock the 
k method of 

the shared mutex, it would have to wait until the main thread is through. Finally, the 
mutex is unlocked and any possible thread that was waiting in the background can 
now resume. 

There is a corner-case scenario where this could potentially be dangerous. The mutex 
function that 
value, or 

has a branch of if/ else statements that return separate values? The unlock method 
mention it 
lution to that: 

the sf : : Lock class. All it does is take in a reference to a mutex in its constructor, at 
bject like that on 
unlocked as 

soon as the lock object is out of scope. Let's take a look at how it can be used: 

sf::Mutex mutex; 

void Test ( ) { 

sf : : Lock lock (mutex) ; 

for (int i = 0; i < 10; ++i) { 

std : : cout << i << std::endl; 
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if (i == 5){ return; } // mutex . unlock ( ) called. 

} 

} // mutex . unlock ( ) called. 

This is a much safer piece of code. Even if there was a possibility of an exception 
he 

program to continue. 

Creating a simple communication 
protocol 

Having covered all of the basics, we're finally ready to get designing! The first 

choice we need to make is which protocol suits our needs better. Losing packets 

in a real-time application like this is not a tragedy. It's more important that data is 

nd all of the 

nefit from 

r. User datagram 

protocol is the way to go. 

Let's flesh out some details of the system we're going to be building by first defining 
some packet types that are going to be exchanged between the server and client, as 
well as deciding on the type of the packet identifier. This information will be held 
inside the PacketTypes . h header: 

using PacketID = sf::Int8; 
enum class PacketTypej 

Disconnect = -1, Connect, Heartbeat, Snapshot, 

Player_Update , Message, Hurt, OutOf Bounds 

}; 

void StampPacket (const PacketTypek l_type, sf::Packet& l_packet) ; 

Note the very last element inside the PacketType enumeration. It isn't an actual 
packet type that will be sent or received. Instead, it simply exists for convenience 
when checking whether a packet type is valid or not, which we'll cover soon enough, 
ching a type 

to a packet. It's implemented in the PacketTypes . cpp file: 

void StampPacket (const PacketTypek l_type, sf::Packet& l_packet) { 
l_packet << PacketID (l_type) ; 

} 
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This function simply converts the provided type argument into a specific integer 
data type supplied by SFML prior to feeding it into the packet instance. Using 
hange the 

communication protocol by adding additional data into the packet. 

Next, let's create a header file that contains the most common bits of information 
shared between both the client and server. We'll simply call it NetworkDef initions .h: 

enum class Network{ 

HighestTimestamp = 2147483647, ClientTimeout = 10000, 

ServerPort = 5600, NullID = -1 

} ; 

using ClientID = inf- 
using PortNumber = unsigned short; 

sides are 

going to be using. 

Keeping a UDP connection alive 

ay to 

the client side, 

has stopped responding, and therefore is deemed to have timed out. A common 
term for this type of mechanism is heartbeat. How it's implemented may differ from 
ase, we're going 
on, but also 

measuring the network delay between both sides. 

For this purpose, it's always best to have the server initiate the heartbeat. It has two 

major benefi 

eat: 


Server Client 

Heartbeat + time 


Client.heartbeat = time 

Client.latency = 
time - Client.heartbeat 


Heartbeat 



Heartbeat = packet, time 
Time = packet, time 


The server is going to keep track of when the last heartbeat to a client was sent. That 
combined with a predefined heartbeat interval enables us to send them at a constant 
the local 

server time is attached to it. It is then sent out to the client. 
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The client side of this operation is much simpler. It is always waiting for a heartbeat 

pt around for 

nowledging 

that a heartbeat was indeed received. 

between 
heartbeat 
ency, is the 

time it takes for data to make a round trip between two hosts. 

ound any 
idth by 

sending data to unreachable hosts. 

Designing the client class 

With all of the things happening on the client side, be it rendering sprites or playing 
sounds or processing user input, it only makes sense to have all of the networking 
code localized inside a single class. This will allow us to communicate with the 
server quickly and easily. Let's begin designing that class, by first taking a look 
at some necessary definitions inside the client . h header: 

#def ine CONNECT_TIMEOUT 5000 // Milliseconds, 
class Client; 

using PacketHandler = std : : function< 

void(const PacketlDS, sf :: Packets, Client*) >; 

The first definition is the amount of milliseconds that it takes for a client to realize 
weaked at any 

time. Following that is a definition of a function type that will be used to handle 

with a pointer 

rmation. 

With that out of the way, we can begin shaping the client class: 

class Client{ 
public : 

Client ( ) ; 

-Client ( ) ; 
bool Connect ( ) ; 
bool Disconnect () ; 
void Listen ( ) ; 

bool Send (sf :: Packets l_packet) ; 
const sf:: Times GetTime ( ) const; 
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const sf::Time& GetLastHeartbeat ( ) const; 
void SetTime (const sf::Time& l_time) ; 
void SetServerlnf ormation (const sf : : IpAddressk l_ip, 
const PortNumber& l_port) ; 

template<class T> 

void Setup (void (T :: *l_handler) 

(const PacketID&, sf :: Packets, Client*), T* l_instance) 

{ 

m_packetHandler = std: :bind (l_handler, l_instance, 
std : : placeholders : :_1, std: : placeholders : :_2, 
std: : placeholders : :_3) ; 

} 


void Setup (void ( *l_handler) (const PacketID&, 
sf :: Packet&, Client*)); 
void UnregisterPacketHandler ( ) ; 
void Update(const sf::Time& l_time) ; 
bool IsConnected ( ) const; 

void SetPlayerName (const std::string& l_name) ; 
sf : : Mutexs GetMutex ( ) ; 
private : 

std:: string m_playerName ; 

sf : : UdpSocket m_socket; 
sf : : IpAddress m_serverlp; 

PortNumber m_serverPort ; 

PacketHandler m_packetHandler ; 
bool m_connected; 
sf::Time m_serverTime ; 
sf::Time m_lastHeartbeat ; 

sf::Thread m_listenThread; 
sf : : Mutex m_mutex; 

}; 


There are a few things to note here. First, we're going to want to support both 
e two 

Setup methods. The first one obviously has to be implemented in the header 
file due to having a template argument. 

Second, this class keeps and manages its own instances of sf : : Mutex 
and sf : : Thread. This way, we can provide a common interface of thread 
synchronization to the outside code. 
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Implementing the client 

With the class definition covered, it's time to actually make it do something, starting 
with the constructor and destructor: 

Client : : Client ( ) : m_listenThread ( &Client : : Listen, this ) { } 

Client :: -Client () { m_socket . unbind () ; } 

In the client constructor's initializer list, we bind the listening thread to the Listen 
method of this class. Threads do not have a default empty constructor, which is why 
this is necessary. The destructor is simply used to unbind the socket we're using. 

Now, let's take a stab at implementing the connection protocol: 

bool Client :: Connect () { 

if (m_connected) { return false; } 
m_socket . bind ( sf : ; Socket : :AnyPort) ; 
sf : : Packet p; 

StampPacket (PacketType: ; Connect, p) ; 
p << m_playerName ; 

if (m_socket . send (p, m_serverlp, m_serverPort ) != 

sf : ; Socket : :Done) 

{ 

m_socket . unbind ( ) ; 
return false; 

} 

m_socket . setBlocking (false) ; 
p . clear ( ) ; 

sf : : IpAddress recvIP; 

PortNumber recvPORT; 
sf::Clock timer; 
timer . restart ( ) ; 

while (timer . getElapsedTime ( ) . asMilliseconds ( ) <CONNECT_TIMEOUT) { 
sf Socket Status s = m_socket . receive (p , recvIP, recvPORT); 
if (s != sf Socket Done) { continue; } 
if (recvIP != m_serverlp) { continue; } 

PacketID id; 

if ( ! (p >> id) ) { break; } 

if ( (PacketType) id != PacketType :: Connect ) { continue; } 

m_packetHandler (id, p, this); 

m_connected = true; 

m_socket . setBlocking (true) ; 

m_lastHeartbeat = m_serverTime ; 

m_listenThread . launch ( ) ; 

return true; 
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} 

std::cout << "Connection attempt failed! Server info: " 

<< m_serverlp << << m_serverPort << std::endl; 

m_socket . unbind ( ) ; 
m_socket . setBlocking (true) ; 
return false; 

} 

The first and most obvious step is checking whether we're already connected to the 
server by checking out the reconnected data member. 

Next, the socket we're using must be bound to a port. A specific port number could 

mputer 

the same 

protocol twice. By using sf : : Socket : : Any Port, we're letting SFML pick a random 
port that isn't being used. 

In order to establish a connection, the client must first send something to the 
server. Since SFML already provides an excellent helper class for easy data 
transfer, sf : : Packet, we're going to be taking full advantage of it. 

After assigning the type Connect to our packet, we also write in the player name 
and send the packet to the server. 

The rest of the code is responsible for correctly handling timeouts. First, we set our 

this in 

use it again, 

port number 

of a response. Additionally, a clock is set up in order to help us determine whether 
we've been waiting too long for a response. 

Next, the code loops as long as the timer stays underneath the predefined time-out 
value, connect_timeout. In each iteration, we invoke the receive method of our 
ccess or the IP 

address it was received from does not match that of our server, we simply skip the 
current iteration. Nobody wants to receive data from an unknown source! 

After verifying that the packet contains an ID and that it matches Connect, we pass 
the received information to the packet handler, set the m_connected flag to true, 
put the socket back into blocking mode, set the last heartbeat value to the current 
time, launch the listening thread, and return true to show success. However, if the 
time to successfully connect runs out, the loop is ended, an error message is printed, 
and the socket is unbound and set to blocking mode again. 


[411 ] 



We Have Contact! - Networking Basics 

ched. Let's take 
a look at what makes it tick: 

void Client :: Listen () { 
sf:: Packet packet; 
sf : : IpAddress recvIP; 

PortNumber recvPORT; 
while (m_connected) { 
packet . clear ( ) ; 
sf Socket Status status = 

m_socket . receive (packet , recvIP, recvPORT); 
if (status != sf :: Socket : :Done) { 
if (unconnected) { 

std::cout << "Failed receiving a packet from " 

<< recvIP << << recvPORT << Status: " 

<< status << std::endl; 
continue ; 

} else { 

std::cout << "Socket unbound." << std::endl; 
break ; 

} 

} 

if (recvIP != m_serverlp) { 

// Ignore packets not sent from the server, 
continue ; 

} 

PacketID p_id; 

if ( ! (packet >> p_id) ) { 

// Non-conventional packet, 
continue ; 

} 

PacketType id = (PacketType) p_id; 

if ( id<PacketType :: Disconnect | | id >=PacketType :: OutOf Bounds ) { 
// Invalid packet type, 
continue ; 

} 

if (id == PacketType :: Heartbeat ) { 
sf : : Packet p; 

StampPacket ( PacketType : :Heartbeat, p) ; 
if (msocket . send (p, m_serverlp, m_serverPort ) != 

sf : : Socket : :Done) 

{ 

std::cout << "Failed sending a heartbeat!" << std::endl; 
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} 

sf : : Int32 timestamp; 
packet >> timestamp; 

SetTime (sf : : milliseconds (timestamp) ) ; 
m_lastHeartbeat = m_serverTime ; 

} else if (m_packetHandler ) { 

m_packetHandler ( (PacketID) id, packet, this); // Handle. 

} 

} 


nformation, the 

listening thread loop is entered. It runs as long as the client is connected to the server, 
receive new 

data. The status of the socket receive method is stored in a local variable, status, 
and checked for success. Because the socket is in blocking mode, the listening thread 
will halt at the m_socket . receive (...) line until some data comes in. 

r message 
If it's not, 

can safely terminate, 
s checked. If 

it does not match the IP of our server, the data is discarded by skipping the current 
loop iteration. Similarly enough, if we're unable to extract the packet ID, or if it does 
not fi 

don't want any malformed or unwelcome packets. 

Next, we check the ID of the packet that was just received. In this particular class, we 
only want to worry about a single type of packets: packet_heartbeat. These are little 
messages that the server sends to all clients for two reasons: time synchronization and 
maintaining a valid connection. Due to unforeseen circumstances, time on the server 
side and the client side can start going out of sync, which eventually can cause serious 
problems. Overwriting the client time with a timestamp coming from the server 
every so often eliminates this problem. In addition to that, this is how both the client 
and server keep track of whether the connection is still alive or not. In the case of our 
client, m_lastHeartbeat holds the latest timestamp received from the server, which 
can be checked for timeouts later. 

t handler 

function to be processed by a different class. 
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to the 

server, let's take a look at how it can be terminated: 

bool Client :: Disconnect () { 

if ( ! m_connected) { return false; } 
sf : : Packet p; 

StampPacket ( PacketType : disconnect, p) ; 
sf :: Socket :: Status s = 

m_socket . send (p, m_serverlp, m_serverPort) ; 
m_connected = false; 

m_socket . unbind () ; // Unbind to close the listening thread, 
if (s != sf :: Socket :: Done) { return false; } 
return true; 

} 

First, the state of the client is checked. We don't need to disconnect if there is no 
ype of 

Disconnect and sent to the server. After the m_connected flag is set to false, we 
unbind our socket and return true or false, based on whether sending the packet 
was successful or not. 

When a socket is in blocking mode, its receive method waits until some 
data arrives before continuing. Having something like that happen in a 
AT separate thread would leave it running, and therefore stop our program 
from quitting. One way to prevent that is by unbinding a socket that is 
being used. It makes the receive method return an error, which we have 
handled in the Listen method of our client class. 

Sending data to the server is quite simple, as this next method shows: 

bool Client Send ( sf :: Packets l_packet) { 
if ( ! m_connected) { return false; } 

if (m_socket . send (l_packet , m_serverlp, m_serverPort) != 
sf : : Socket : : Done) 

{ 

return false; 

} 

return true; 

} 

We take in a reference to an existing packet that needs to be sent out. The method 
immediately returns false if we're not connected to the server or if the send 
method of our socket returns anything else than sf : : Socket : : Done. 
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o be used 

by this class. The member function version of this method was already implemented 
in the header file, and all that's left is handling a function pointer version: 

void Client: : Setup (void (*l_handler) 

(const PacketID&, sf::Packet&, Client*)) 

{ 

m packetHandler = std: :bind (l_handler, 

std: : placeholders : :_1, std: placeholders: :_2, 
std: placeholders: :_3) ; 

} 

ove any ties 

void Client: : UnregisterPacketHandler ( ) { 
m packetHandler = nullptr; 

} 

Last but not least, the update method: 

void Client :: Update (const sf::Time& l_time) { 
if ( ! m_connected) { return; } 
m_serverTime += l_time; 

if (m_serverTime . asMilliseconds ( ) < 0){ 
m_serverTime -= sf : billiseconds ( 

sf : : Int32 (Network : : HighestTimestamp) ) ; 
m_lastHeartbeat = m_serverTime; 
return; 

} 

if (m_serverTime . asMilliseconds ( ) - 
m__lastHeartbeat . asMilliseconds ( ) > = 
sf : : Int32 (Network : : ClientTimeout) ) 

{ 

// Timeout. 

std::cout << "Server connection timed out!" << std::endl; 
Disconnect ( ) ; 

} 

} 

ng the time 

between updates to the server time. 
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e 

seconds 

that have passed since the beginning is represented by a signed 32-bit integer. Its 
e negatives, 
n fact, the 
r the 

scenario is not 

worthy of ignoring simply because it's unlikely to happen. Subtracting the highest 
time around 
ened. 

The update method is also where we check for our connection timing out. If the 
difference between current time and the last heartbeat received from the server 
is greater or equal to the timeout value in milliseconds, the Disconnect method 
is invoked. 


The server class 

Now, it's time to take a look at the way things are handled on the other side of the 
wire. Let's begin by defining some constants: 

#def ine HEARTBEAT_INTERVAL 1000 // Milliseconds. 

#def ine HEARTBEAT_RETRIES 5 

retry five 
nal information 
t holds it all: 

struct ClientInfo{ 

sf : : IpAddress m_clientIP; 

PortNumber m_clientPORT; 
sf::Time m_lastHeartbeat ; 
sf::Time m_heartbeatSent ; 
bool m_heartbeatWaiting; 
unsigned short m_heartbeatRetry ; 
unsigned int m_latency; 

Clientlnfo ( const sf : : IpAddressk l_ip, const PortNumberk l_port, 
const sf::Time& l_heartbeat) : m_clientIP ( l_ip) , 
m clientPORT(l port) , m_lastHeartbeat (l_heartbeat) , 
m_heartbeatWaiting (false) , m_heartbeatRetry ( 0 ) , m_latency(0) 

{} " 
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Clientlnfok operator= 
m_clientIP 
m_clientPORT 
m_lastHeartbeat 
m_heartbeatSent 
m_heartbeatWaiting 
m_heartbeatRetry 
m_latency 
return *this; 



const Clientlnfok l_rhs) { 

= l_rhs .m_clientIP; 

= l_rhs .m_clientPORT; 

= l_rhs . m_lastHeartbeat ; 

= l_rhs . m_heartbeatSent ; 

= 1 rhs . m_heartbeatWaiting ; 
= l_rhs . m_heartbeatRetry ; 

= l_rhs . m_latency ; 


d to know 

when the last heartbeat was sent to them, whether the server is waiting for a 
heartbeat response, the number of heartbeat retries made, and the current latency 
the client has. 



Keeping track of latency provides tons of potential benefits, ranging from 
assessing quality of service and accurate matchmaking to maximizing the 
accuracy of a network simulation. 


Next, the data types we're going to be using throughout the Server class deserve 
a look: 

using Clients = std: :unordered_map<ClientID, ClientInfo>; 
class Server; 

using PacketHandler = std: : functioncvoid (sf : : IpAddress&, 

const PortNumberk, const PacketID&, sf :: Packets, Server* ) > ; 
using TimeoutHandler = std :: function<void (const ClientID&) > ; 

As you can see, this class also uses a custom function that is going to be handling 
incoming packets. In addition to that, we're going to need to be able to process client 
timeouts outside of this class as well, which can also be done through means of using 
a function pointer. 

We have everything we need, so let's write the Server class header: 

class Server{ 
public : 

template <class T> 

Server (void (T :: *l_handler) (sf : : IpAddressk, const PortNumber&, 
const PacketID&, sf : : Packets, Server*), 

T* l_instance) : m_listenThread ( &Server :: Listen, this) 

{ 
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m packetHandler = std: :bind (l_handler, l_instance, 
std: placeholders: :_1, std: placeholders: :_2, 
std: placeholders: :_3, std: placeholders: :_4, 
std: placeholders: :_5) ; 


Server (void ( *l_handler) (sf :: IpAddressS, const PortNumberS, 
const PacketlDS, sf :: Packets;, Server*)); 

-Server ( ) ; 

template<class T> 

void BindTimeoutHandler (void (T : :*l_handler) 

(const ClientIDS) , T* l_instance) 

{ 

m_timeoutHandler = std :: bind ( l_handler , l_instance, 
std: placeholders: :_1) ; 

} 

void BindTimeoutHandler (void (*l_handler) (const ClientIDS)); 

bool Send (const ClientIDS l_id, sf:: Packets l_packet) ; 

bool Send ( sf : : IpAddressS l_ip, const PortNumberS 1 port, 
sf:: Packets l_packet) ; 

void Broadcast ( sf :: Packets 1 packet, 

const ClientIDS l_ignore = ClientID (Network :: NullID) ) ; 

void Listen ( ) ; 

void Update (const sf::Time& l_time) ; 

ClientID AddClient ( const sf :: IpAddressS l_ip, 
const PortNumberS l_port) ; 

ClientID GetClientID ( const sf :: IpAddressS l_ip, 
const PortNumberS l_port) ; 

bool HasClient ( const ClientIDS l_id) ; 

bool HasClient (const sf :: IpAddressS l_ip, 
const PortNumberS l_port) ; 

bool GetClientlnfo ( const ClientIDS l_id, ClientlnfoS l_info) ; 

bool RemoveClient (const ClientIDS l_id) ; 

bool RemoveClient (const sf :: IpAddressS l_ip, 
const PortNumberS l_port) ; 


void DisconnectAll ( ) ; 
bool Start (); 
bool Stop ( ) ; 
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bool I sRunning ( ) ; 

unsigned int GetClientCount ( ) ; 
std::string GetClientList ( ) ; 

sf : : MutexS GetMutex ( ) ; 
private : 

void Setup ( ) ; 

ClientID m_lastID; 

sf : : UdpSocket m_incoming; 
sf : :UdpSocket m_outgoing; 

PacketHandler m_packetHandler ; 

TimeoutHandler m_timeoutHandler ; 

Clients m_clients; 
sf::Time m_serverTime ; 

bool m_running; 

sf : :Thread m_listenThread; 
sf : :Mutex m_mutex; 

size_t m_totalSent; 
size_t m_totalReceived; 

}; 

Just like the client class, we want to support both member functions and regular 
Iso 

or sending 
different 

operations, which sometimes may result in runtime errors and data corruption. For 
an added bonus, we're also keeping track of all data sent and received. 

Implementing server 

Let's start by taking a look at the second constructor and the destructor of this class: 

Server :: Server (void ( *l_handler) (sf : : IpAddress&, const PortNumber&, 
const PacketlDSc, sf:: Packets, Server*)) 

: m_listenThread (SServer :: Listen, this) 

{ 

// Bind a packet handler function. 
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m_packetHandler = std : : bind ( l_handler , 

std: :placeholders : :_1, std: : placeholders : : 2 , 

std: placeholders: :_3, std: placeholders: :_4, 
std: placeholders: :_5) ; 


Server :: -Server () { StopO; } 

Nothing too interesting is happening here. The constructor simply binds the 

Stop 

o 

need a function to handle client timeouts: 

void Server: : BindTimeoutHandler (void ( *l_handler ) 

(const ClientlDSc) ) 

{ 

m_timeoutHandler = std :: bind ( l_handler, std :: placeholders :: _1 ) ; 

} 


g on your 

application. One of the main ways we're going to be taking advantage of this feature 
is de-spawning entities in the game world. 

Now, let's take a peek at how we start our server: 

bool Server :: Start () { 

if (m_running) { return false; } 

if (m_incoming . bind (SERVER_PORT) != sf :: Socket : :Done) { 
return false; 

} 

m_outgoing . bind (sf : : Socket : :AnyPort) ; 

Setup ( ) ; 

std::cout << "Incoming port: " << 

m_incoming . getLocalPort ( ) << ". Outgoing port: " 

<< m_outgoing . getLocalPort ( ) << std::endl; 
m_listenThread . launch ( ) ; 
m_running = true; 
return true; 

} 
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ocket to the 

predesignated port number, false is returned. Otherwise, the outgoing socket is 
bound to a random port, a Setup method is invoked to set up some data members, 
the listening thread is launched, and the m running flag is set to true. You can stop 
the server like this: 

bool Server :: Stop () { 

if ( !m_running) { return false; } 

DisconnectAll () ; 
m_running = false; 

m_incoming . unbind () ; // Stops the listening thread, 
return true; 

} 


If the server is actually running, a DisconnectAll method is invoked to drop 
all the clients. The running flag is then set to false and the incoming socket is 
ocket 

is in blocking mode. 

Here's a little helper method that initializes some data members to their default states: 

void Server :: Setup () { 
m_lastID = 0; 
m_running = false; 
m_totalSent = 0; 
m_totalReceived = 0; 

} 

This is invoked every time a server is started, as demonstrated previously. 

Sending data to clients is fairly straightforward, as you can see here: 

bool Server :: Send ( const ClientID& l_id, sf::Packet& l_packet) { 
sf::Lock lock (m mutex) ; 

auto itr = m_clients . f ind ( 1 id) ; 

if (itr == m_clients . end ( ) ) { return false; } 
if (m_outgoing . send ( l_packet , itr- >second . m_clientIP, 
itr- >second . m_clientPORT) != sf :: Socket : :Done) 

{ 

std::cout << "Error sending a packet..." << std::endl; 
return false; 

} 

m_totalSent += l_packet . getDataSize ( ) ; 
return true; 

} 
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With a little bit of STL find magic, we retrieve the client's information from the 
container it's stored in and send the packet out. 



Note the mutex lock in the very first line. This is done to ensure that 
the client isn't removed from the container right in the middle of a 
send operation. 


] 


As a side bonus, it's also nice to keep track of how much data was sent and received. 
Here, we make use of the getDataSize method that sf : : Packet provides to do 
just that. 

For convenience, we could also write an overloaded version of the Send method 
that doesn't require a client: 

bool Server :: Send (sf :: IpAddressS l_ip, 

const PortNumberS l_port, sf::Packet& l_packet) 

{ 

if (m_outgoing . send (l_packet , l_ip, l_port) != sf :: Socket : :Done) 

{ 

return false; 

} 

m_totalSent += l_packet . getDataSize () ; 
return true; 

} 

. Broadcasting 
ut anything 

from chat messages to entity states. Let's write it: 

void Server :: Broadcast ( sf Packet& l_packet, 
const ClientIDS l_ignore) 


sf : :Lock lock (mmutex) ; 

for (auto Sitr : m_clients) 

{ 

if (itr. first != l_ignore) { 

if (m_outgoing . send ( l_packet , itr . second . m_clientIP , 
itr . second . m_clientPORT) != sf :: Socket :: Done) 

{ 

std::cout << "Error broadcasting a packet to client: " 
<< itr. first << std::endl; 
continue ; 

} 
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m_totalSent += l_packet . getDataSize () ; 

} 

} 

} 


each client's ID is 

checked for matching the l_ignore argument, which can be used to specify a client 
ID that shouldn't receive the packet being broadcasted. If data is successfully sent 
out, its size is added to the sent data counter. 

processing 

incoming data. Let's take a look at the Listen method: 

void Server :: Listen () { 
sf : : IpAddress ip; 

PortNumber port ; 
sf:: Packet packet; 
while (m_running) { 
packet . clear ( ) ; 
sf :: Socket :: Status status = 

m_incoming . receive (packet , ip, port); 
if (status != sf :: Socket : :Done) { 
if (m_running) { 

std::cout << "Error receiving a packet from: " 

<< ip << << port << ". Code: " << 

status << std::endl; 
continue; 

} else { 

std::cout << "Socket unbound." << std::endl; 
break ; 

} 

} 


m_totalReceived += packet . getDataSize () ; 

PacketID p_id; 
if ( ! (packet >> p_id) ) { 
continue ; 

} // Non-conventional packet. 

PacketType id = (PacketType) p_id; 

if ( id<PacketType :: Disconnect || id>=PacketType :: OutOf Bounds ) { 
continue ; 

} // Invalid packet type. 
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if (id == PacketType :: Heartbeat ) { 
sf : : Lock lock (m_mutex) ; 
for (auto &itr : m_clients) { 

if ( itr . second . m_clientIP ! = ip | 
itr . second . m_clientPORT != port) 

{ 

continue ; 

} 

if (! itr . second . m_heartbeatWaiting) { 

std : : cout << "Invalid heartbeat packet received!" 

<< std : : endl ; 
break ; 

} 

itr . second . m_ping = m_serverTime . asMilliseconds ( ) - 

itr . second . m_heartbeatSent . asMilliseconds ( ) ; 
itr . second . m_lastHeartbeat = m_serverTime; 
itr . second . m_heartbeatWaiting = false; 
itr . second . mheartbeatRetry = 0; 
break ; 

} 

} else if (m_packetHandler) { 

m_packetHandler ( ip , port, (PacketID) id, packet, this); 


} 


} 


merited. After 


while loop, 

r incoming 
k from the loop 

if the server is no longer running and the return status from the receive method 
was anything but sf : : Socket : : Done. 


After all of the packet ID checks, we get to the heartbeat part of the code. A flag is set 
up to indicate whether a client that sent the heartbeat was located or not. 



Note that we lock our mutex here, because we're about to start iterating 
over the list of clients in order to find the one that sent in the heartbeat 
response. 


] 


the server 

is currently waiting for a heartbeat response from them. We only want clients to be 
latency and 

prevent potential cheating attempts. 
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Given that this is a valid heartbeat response, latency is calculated by subtracting 
the time a heartbeat was sent to this particular client from the current server time. 
The current timestamp is also stored in m_lastHeartbeat, which we'll be using to 
determine when to dispatch the next one. Afterwards, the heartbeat waiting flag is 
set to false and the retry counter is set back to 0. 

Next, let's implement adding clients: 

ClientID Server : :AddClient (const sf : : IpAddress& l_ip, 
const PortNumber& l_port) 

{ 

sf : :Lock lock (m mutex) ; 

for (auto &itr : m_clients) { 

if ( itr . second . m_clientIP == l_ip && 
itr . second . m_clientPORT == l_port) 

{ 

return ClientID (Network : :NullID) ; 

} 

} 

ClientID id = m_lastID; 

Clientlnfo info(l_ip, l_port, m_serverTime) ; 
m_clients . insert (std: :make_pair (id, info) ) ; 

++m_lastID ; 
return id; 

} 

to ensure 
modify 
t container 

and return -1 if a specified IP and port combination already exists. Otherwise, a 
e container, 

followed by an increment operation of m_lastlD. 
their 

IP address and port number. Let's write a way to do just that: 

ClientID Server :: GetClientID (const sf : : IpAddress& l_ip, 
const PortNumber& l_port) 

{ 

sf : :Lock lock (mjnutex) ; 

for (auto &itr : m_clients) { 

if ( itr . second . m_clientIP == l_ip && 
itr . second . m_clientPORT == l_port) 

{ 

return itr. first; 
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} 

} 

return ClientID (Network : :NullID) ; 

} 

mation matches 
he mutex 

in order to safely access this data. 

Next up, we need some setters and getters: 

bool Server :: HasClient (const ClientID& l_id) { 

return (m__clients . f ind ( 1 id ) != m_clients . end ( ) ) ; 

} 

bool Server :: HasClient (const sf : : IpAddress& l_ip, 
const PortNumber& l_port) 

{ 

return (GetClientID (l_ip, l_port) >= 0) ; 

} 


bool Server :: IsRunning () { return m_running; } 
sf::Mutex& Server :: GetMutex () { return m_mutex; } 


bool Server :: GetClientlnfo (const ClientID& l_id, 

ClientInfo& l_info) 

{ 

sf : :Lock lock (mmutex) ; 

for (auto &itr : m_clients) { 

if (itr. first == 1 id) { 

l_info = itr. second; 
return true; 

} 

} 

return false; 

} 

In this case, the provided reference to a client info structure is simply overwritten 
hanks to the 

overloaded assignment operator that clientinfo provides. Once again, the mutex 
is locked because we're accessing data that can be removed or overwritten in the 
middle of the search otherwise. 
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bool Server :: RemoveClient ( const ClientID& l_id) { 
sf::Lock lock (m_mutex) ; 
auto itr = m_clients . f ind (l_id) ; 
if (itr == m_clients . end ( ) ) { return false; } 
sf : : Packet p; 

StampPacket ( PacketType : : Disconnect, p) ; 

Send (l_id, p) ; 
m_clients . erase (itr) ; 
return true; 

} 

The first one simply locates client information by using the find method of a 
container it's stored in. If one was found, a disconnect packet is created and sent 
to the client before it gets erased. The second variation varies in its search method, 
but carries out the same basic idea: 

bool Server :: RemoveClient ( const sf : : IpAddressk l_ip, 
const PortNumber& 1 port) 

{ 

sf : :Lock lock (mjnutex) ; 

for (auto itr = m_clients . begin () ; 
itr != m_clients . end ( ) ; ++itr) 

{ 

if ( itr- >second . m_clientIP == l_ip && 
itr- >second . m_clientPORT == l_port) 

{ 

sf : : Packet p; 

StampPacket ( PacketType :: Disconnect , p); 

Send(itr->first, p); 
m_clients . erase ( itr) ; 
return true; 

} 

} 

return false; 

} 

d modified, 
f them out 
at the same time? 

void Server :: DisconnectAll () { 
if ( ! m_running) { return; } 
sf : : Packet p; 

StampPacket ( PacketType : : Disconnect, p) ; 
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Broadcast (p) ; 

sf : :Lock lock (m_mutex) ; 

m_clients . clear ( ) ; 

} 

onnect packet is 
d of just one. 
ompletely. 

Last but definitely not least, here's the update method: 

void Server :: Update (const sf::Time& l_time) { 
m_serverTime += l_time; 

if (m_serverTime . asMilliseconds ( ) < 0){ 

m_serverTime -= sf : tmilliseconds (HIGHEST_TIMESTAMP) ; 
sf : :Lock lock (mmutex) ; 
for (auto &itr : m_clients) 

{ 

Itr . second . m_lastHeartbeat = 
sf : tmilliseconds (std: tabs ( 

itr . second . m_l as t Heartbeat . asMilliseconds ( ) - 

HIGHEST_TIMESTAMP) ) ; 

} 

} 


sf : :Lock lock (mmutex) ; 

for (auto itr = m_clients . begin () ; itr != m_clients . end ( ) ; ) { 
sf::Int32 elapsed = 

m_serverTime . asMilliseconds ( ) - 

itr- > second . m_lastHeartbeat . asMilliseconds ( ) ; 
if (elapsed >= HEARTBEAT_INTERVAL) { 
if (elapsed >= CLIENT_TIMEOUT 

| itr- >second . m_heartbeatRetry > HEARTBEAT_RETRIES ) 

{ 

// Remove client. 
std::cout << "Client " << 

itr->first << " has timed out." << stdttendl; 
if (m_timeoutHandler) { m_timeoutHandler (itr->first) ; } 
itr = m_clients . erase ( itr) ; 
continue ; 

} 

if ( ! itr- >second . m_heartbeatWaiting | | (elapsed >= 

HEARTBEAT_INTERVAL * ( itr- >second . m_heartbeatRetry + 1) ) ) 

{ 

/ / Heartbeat 
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if ( itr- >second . m_heartbeatRetry >= 3){ 

std::cout << "Re-try(" << itr- >second . m_heartbeatRetry 
<< ") heartbeat for client " 

<< itr->first << std::endl; 

} 

sf : : Packet Heartbeat; 

StampPacket (PACKET_HEARTBEAT, Heartbeat) ; 

Heartbeat << m_serverTime . asMi Hi seconds () ; 

Send ( itr- >first , Heartbeat); 

if ( itr- >second . m_heartbeatRetry == 0) { 

itr- >second . m_heartbeatSent = m_serverTime ; 

} 

itr- >second . m_heartbeatWaiting = true; 

++itr- >second . m_heartbeatRetry ; 

m_totalSent += Heartbeat . getDataSize ( ) ; 


++itr ; 



running out 
f every client 
lock the 
any of the 
ad. 

After the mutex lock, we begin iterating over clients and measuring the time elapsed 
between now and the last heartbeat. If this time exceeds or is equal to the interval we 
want heartbeats to be sent out at, we first check if it either also exceeds the timeout 
interval or if the number of heartbeat retries has exceeded the designated value, 
container. 

or a reply 

from the client, or if it's time to retry sending another heartbeat, a packet is 
his is a first 

try sending it, the server time also gets stored inside the m_heartbeatSent 
data member of a client entry. 
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A simple chat application 

Id something 

with it! How about a neat little console-based chat program? Let's start with the 
server by creating a separate project and a new file called Server_Main . cpp. 

The first thing we're going to need is a packet handler: 

void Handler ( sf :: IpAddress& l_ip, const PortNumber& l_port, 

const PacketID& l_id, sf::Packet& l_packet, Server* l_server) 

{ 

ClientID id = l_server- >GetClientID ( l_ip , l_port) ; 
if (id >= 0) { 

if ( (PacketType) l_id == PacketType :: Disconnect) { 
l_server- >RemoveClient ( l_ip, l_port) ; 
sf : : Packet p; 

StampPacket (PacketType: : Message, p) ; 
std::string message; 

message = "Client left! " + l_ip . toString ( ) + 

+ std: : to_string (l_port) ; 
p << message; 

l_server- >Broadcast (p, id); 

} else if (( PacketType ) l_id == PacketType :: Message ) { 
std::string receivedMessage; 
l_packet >> receivedMessage; 

std:: string message = l_ip . toString ( ) + + 

std : : to_string ( l_port ) + " :" + receivedMessage; 
sf : : Packet p; 

StampPacket ( PacketType : : Message, p) ; 
p << message; 

l_server- >Broadcast (p, id); 

} 

} else { 

if ( (PacketType) l_id == PacketType :: Connect ) { 

ClientID id = l_server- >AddClient ( l_ip , l_port) ; 
sf:: Packet packet; 

StampPacket ( PacketType : : Connect, packet) ; 
l_server- >Send ( id, packet); 

} 

} 

} 

As we're going to be providing a pointer to this function to our Server class, the 
fingerprint has to match exactly. The function itself starts by first establishing 
.If it 
packets: 

Disconnect and Message. 
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In a case of client disconnect, we create a message packet that is broadcasted to 
an incoming 

message from one of the clients, it is first extracted and attached to a string that 

icknames this 

roadcasted 

to every client, except the one that sent the message to begin with, 
t packets. 

When one is received, the IP address and port are added and a connect packet 
is sent back to the client. 

What kind of a server would it be if it didn't have the ability to process commands? 
Let's write a function that will be running in a separate thread and process 
user input: 

void CommandProcess (Server* l_server) { 
while (l_server- >IsRunning ( ) ) { 
std : : string str; 
std: :getline (std: :cin, str); 
if (str == " !quit") { 
l_server->Stop () ; 
break; 

} else if (str == "dc"){ 

l_server- >DisconnectAll ( ) ; 
std::cout << "DC..." << std::endl; 

} else if (str == "list"){ 

std : : cout << l_server- >GetClientCount ( ) 

<< " clients online:" << std::endl; 
std:: cout << l_server- >GetClientList ( ) << std::endl; 

} 


} 

Note that std: :getline is a blocking function. If the program stops running, the 
thread that this function is running on will still be blocking until some user input 
that stops 

the server, which is what " ! quit " does. Once the server stop method is invoked, 
it also breaks the loop just to be safe. 

The other two commands are pretty standard. One simply disconnects all users, 
overed 

GetClientCount or GetClientList, since they're fairly basic and are not required 
for the server to run. You can find the implementation of these two methods in the 
source code of this book. 
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Now it's time to assemble and run our code: 

int main ( ) { 

Server server (Handler) ; 

if ( server . Start ()) { 

sf::Thread c ( &CommandProcess , ^server) ; 
c . launch ( ) ; 

sf : :Clock clock; 
clock . restart ( ) ; 
while ( server . IsRunning ()) { 

server . Update (clock . restart ( ) ) ; 

} 

std : : cout << "Stopping server. . . " << std: : endl ; 


system ("PAUSE") ; 
return 0 ; 

} 

This is quite a basic setup for the entry point of an application like this. First, we 
create an instance of the Server class and provide a function pointer that is going 
to be handling packets in its constructor. We then attempt to start the server and 
catch the return value of that in an if statement. If a successful start took place, a 
command thread is set up and launched. An instance of sf : : Clock is created and 
s the server 

is running and updates it with the elapsed time value between iterations. That's all 
we need to have in a chat server! 


The chat client 

it and 

sending messages back and forth. In a separate project, let's create a file named 
Client_Main . cpp and begin writing the client portion of the code, starting with 
a packet handler: 

void HandlePacket ( const PacketID& l_id, 
sf::Packet& l_packet, Client* l_client) 

{ 

if ( (PacketType) l_id == PacketType : :Message) { 
std::string message; 
l_packet >> message; 
std : : cout << message << std::endl; 
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} else if ( (PacketType) l_id == PacketType :: Disconnect ) { 
l_client- disconnect ( ) ; 

} 

} 

support 

class to fall back on. The client responds to two types of packets: messages and 
disconnects. In case a message pops in, it's extracted and simply printed in 
the console window. If a disconnect packet arrives from the server, the client's 
Disconnect method is invoked. 

Next, the function that will be running in a command thread: 

void CommandProcess (Client* l_client) { 
while (l_client- >IsConnected ( ) ) { 
std : : string str; 
std: :getline (std: :cin, str); 
if (str ! = " " ) { 

if (str == " Iquit" ) { 

l_client- >Disconnect ( ) ; 
break ; 

} 

sf : : Packet p ; 

StampPacket (PacketType : : Message, p) ; 
p << str; 

l_client - >Send (p) ; 

} 

} 

} 

std : : getline function, except we're only going to be processing the quit command 
d sent out to 

the server. Keep in mind that because the std : : getline function is a blocking one, a 
e server, just to 
o be closed. 

f our 

chat client: 

void main(int argc, char** argv) { 
sf : ; IpAddress ip; 

PortNumber port ; 
if (argc == 1) { 

std::cout << "Enter Server IP: 
std: : cin >> ip; 
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std::cout << "Enter Server Port: " 
std::cin >> port; 

} else if (argc == 3){ 
ip = argv[l]; 
port = atoi (argv [2] ) ; 

} else { 

return; 

} 


Client client; 

client . SetServerlnf ormation ( ip , port) ; 
client . Setup (&HandlePacket) ; 
sf::Thread c ( &CommandProcess , &client) ; 
if (client . Connect ()) { 
c . launch ( ) ; 
sf : :Clock clock; 
clock . restart ( ) ; 
while (client . IsConnected ()) { 

client .Update (clock . restart ( ) ) ; 

} 

} else { 

std::cout << "Failed to connect." << std::endl; 

} 

std::cout << "Quitting..." << std::endl; 
sf : : sleep (sf : : seconds ( 1 . f ) ) ; 

} 

We begin by setting up a few variables to hold the IP address and port of the server. 
For extra credit, let's add support for command line arguments. If none are provided, 
onsole 

window. Otherwise, the command-line arguments are read in and used for the 
same purpose. 

Moving further, we see that an instance of Client is created and set up with the 

function 

attempts 

to connect to the server, and if the connection is successful, the command thread is 
launched, an instance of sf : : Clock is created, and the main loop of the program is 
entered, where the client gets updated. 
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With this, we have a fairly simple yet functional chat application: 


C:\Repositories\SFML by example\Chapter 13\Debug\Server.exe 


Incoming port: 5600. Outgoing port: 55282 
Beginning to listen... 

Re-try<3> heartbeat for client 0 

BR e-ti t y(4) heartbeat for client 0 

|Re-try<5) heartbeat for client 0 

(Client 0 has timed out. 

0Re-try<3> heartbeat for client 1 

Re-try<4> heartbeat for client 1 

[Re— try<5> heartbeat for client 1 

Client 1 has timed out. 


@ S3 




exampleXCha 


- ° 


C:\Repositories\SFML by example\Chapter .. 



Enter Server IP: 127.0.0.1 

Enter Server Port: 5600 

Bound client to port: 49599 

Attempting to connect to: 127.0.0.1:5600 

Beginning to listen... 

Hello? How are you? 

127.0.0.1:58575 :I'm doing well, thank you? 


Enter Server IP: 127.0.0.1 
Enter Server Port: 5600 
Bound client to port: 58575 
Attempting to connect to: 127.0.0.1:5600 
Beginning to listen... 

127.0.0.1:49599 :Hello? How are you? 

I'm doing well, thank you? 


Summary 

fundamentals, which includes the basics of socket programming, utilization of 
ns, we're 

finally ready to tackle actual game networking! In the final chapter of this book, 
we're going to integrate this network code into our existing code base, turning a 
lonely single player RPG into an exciting arena of player versus player combat! 
See you there! 
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e contents of 
h nothing more 

than an interest and the will to create. Now that we're at the climax of our tale, why 
not end with a bang? Let's bring things back full circle and combine the framework 
we've developed with capabilities of networking to bring the third project of this 
simple 

information exchange, but also through gameplay. 

In this chapter, we're going to cover: 

• Building a game server that supports previously implemented mechanics 

• Exchanging entity data over a network 

• Transforming existing game code into a client application 

• Implementing player versus player combat 

• Hiding network latency by smoothing out entity movement 

There's a lot of code to cover, so let's get started! 

Use of copyrighted resources 

and sound 

effects that we're going to be using for our final project: 

• Simple small pixel hearts by C.Nilsson under the CC-BY-SA 3.0 license: 
http : // opengameart . org/ content/ simple -small -pixel -hearts 

• Grunt by n3b under the CC-BY 3.0 license: http : //opengameart . org/ 
content /grunt 
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• Swishes sound pack by artisticdude under the CCO license (public domain): 
http : //opengameart . org/ content/ swishes -sound-pack 

• 3 Item sounds by Michel Baradari under the CC-BY 3.0 license: 
http : / / opengameart . org/ content/3 -item- sounds 


Shared code 

both the 

client and the server side, let's discuss that first, starting with the way data exchange 
between both sides is made. 

on any and 
and forth, 
s are going 
y taking a 

look at the EntitySnapshot . h file: 

struct EntitySnapshot { 
std::string m_type; 
sf::Vector2f m_position; 
sf::Int32 m_elevation; 
sf::Vector2f m_velocity; 
sf::Vector2f m_acceleration; 
sf : :Uint8 m_direction; 
sf::Uint8 m_state; 
sf::Uint8 m_health; 
std:: string m_name; 

} ; 


The information we're going to be updating constantly for any given entity consists 
s facing as well as 

the state it's in, and the entity's health and name. The type of an entity is also sent in 
a snapshot and used when creating the entity on the client side. 



In this example, the order of the data members in the 
EntitySnapshot structure may not be the most efficient. Ordering 
data in your structures from biggest to smallest can help reduce their 
size, and therefore the bandwidth overhead. Structure alignment and 
packing are not going to be covered here, but it's a worthy subject to 
look into. 
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erloading 

the bitwise shift operators of sf : : Packet to support custom data types, such as 
EntitySnapshot: 

sf:: Packets operator <<( sf :: Packets l_packet, 
const EntitySnapshotS l_snapshot) ; 

sf:: Packets operator >>( sf :: Packets l_packet, 

EntitySnapshotS l_snapshot) ; 

Actual implementation of these overloads exists inside the EntitySnapshot . cpp file: 

sf:: Packets operator << (sf :: Packets l_packet, 
const EntitySnapshotS l_snapshot) 

{ 

return l_packet << l_snapshot . m_type << l_snapshot . m_name 
<< l_snapshot . m_position . x << l_snapshot . m_position . y 
<< l_snapshot . m_elevation << l_snapshot .m_velocity.x 
<< l_snapshot . m_velocity . y << l_snapshot . m_acceleration . x 
<< l_snapshot . m_acceleration . y << l_snapshot . m_direction 
<< l_snapshot . m_state << l_snapshot .m_health; 

} 


sf:: Packets operator >>( sf :: Packets l_packet, 

EntitySnapshotS l_snapshot) 

{ 

return l_packet >> l_snapshot . m_type >> l_snapshot . m_name 
>> l_snapshot . m_position . x >> l_snapshot . m_position . y 
>> l_snapshot . m_elevation >> l_snapshot .m_velocity.x 
>> l_snapshot . m_velocity . y >> l_snapshot . m_acceleration . x 
>> l_snapshot . m_acceleration . y >> l_snapshot . m_direction 
>> l_snapshot . m_state >> l_snapshot .m_health; 

} 

Other data exchanges are going to be more specific to the situation, so we're going 
ever, is 

updating the Network enumeration in the NetworkDef initions . h file with a new 
value that is going to be used as a delimiter between different types of data in a 
specific packet: 

enum class Network{ 

HighestTimestamp = 2147483647, ClientTimeout = 10000, 

ServerPort = 5600, NullID = -1, PlayerUpdateDelim = -1 

} ; 

As we're going to work with the specific packet type that uses this delimiter on both 
the client and the server, its place is within the shared code space. 
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Additional components 

rver and 

client need to be marked and assigned a unique identifier. This is where the 
C_Client component comes in: 

class C_Client : public C_Base{ 
public : 

C_Client() : C_Base (Component : : Client) , 
m_clientID ( (Client ID) Network : : Null ID) { } 
void Readln ( std : : stringstreams l_stream) { } 

ClientID GetClientID () const { return m_clientID; } 
void SetClientID (const ClientIDS l_id) { m_clientID = l_id; } 
private : 

ClientID m_clientID; 

} ; 

ore player 

nicknames. This can be accomplished by implementing a name component: 

class C_Name : public C_Base{ 
public : 

C_Name ( ) : C_Base (Component : :Name) { } 

void Readln ( std :: stringstreams l_stream) { l_stream >> m_name; } 
const std :: strings GetName () const { return m_name; } 
void SetName (const std::strings l__name) { m_name = l_name; } 
private : 

std::string m_name; 

} ; 

It's a common thing in games to have a small cooldown period where an entity 
cannot be attacked, possibly also defining how long its hurting/ death animation 
should last. Components that allow and define such functionality would ideally 
have to inherit from a base class, which simplifies the process of timing such events: 

class C_TimedComponentBase : public C_Base{ 
public : 

C_TimedComponentBase (const Components l_type) 

: C_Base (l_type) , m_duration ( sf :: milliseconds ( 0 )){ } 
virtual ~C_TimedComponentBase ( ) { } 

const sf::Time& GetTimer () const { return m_duration; } 

void SetTimer ( const sf::Time& l_time) { m_duration = l_time; } 

void AddToTimer ( const sf::Time& l_time) { m_duration += l_time; } 
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void Reset(){ m_duration = sf :: milliseconds ( 0 ) ; } 
protected: 

sf::Time m_duration; 

} ; 

One component that will make use of the base timed class will be c_Health: 

using Health = unsigned int ; 

class C_Health : public C_TimedComponentBase { 
public : 

C_Health() : C_TimedComponentBase (Component : : Health) , 
m_hurtDuration ( 0 ) , m_deathDuration ( 0 ) {} 
void Readln ( std : : stringstream& l_stream) { 

l_stream >> m_maxHealth >> m_hurtDuration >> m_deathDuration; 
m_health = m_maxHealth; 

} 

Health GetHealth () const { return m_health; } 

Health GetMaxHealth () const { return m_maxHealth; } 

void SetHealth (const Healthk l_health) { m_health = l_health; } 

void ResetHealth ( ) { m_health = m_maxHealth; } 

sf::Uint32 GetHurtDuration ( ) { return m_hurtDuration; } 
sf::Uint32 GetDeathDuration ( ) { return m_deathDuration; } 
private : 

Health m_health; 

Health m_maxHealth; 
sf::Uint32 m_hurtDuration; 
sf::Uint32 m_deathDuration; 

} ; 

As you can see, it holds values for the current entity health, its maximum health 
urt 

and dying. 

Naturally, we're going to need more entity message and event types in order 
in 

the following code snippet: 

enum class EntityMessage { 

Move, Is_Moving, Frame_Change , State_Changed, 

Direction_Changed, Switch_State , Attack, 

BeingAttacked, Hurt, Die, Respawn, Removed_Entity 

} ; 

enum class EntityEvent{ 

Spawned, Despawned, Colliding_X, Colliding_Y, 
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Moving_Left, Moving_Right , Moving_Up, Moving_Down, 

Elevation_Change , Became_Idle, Began_Moving, BeganAttacking 

} ; 

The EntityManager class is also going to be shared between both sides. Some 
adjustments have to be made to its AddEntity and RemoveEntity methods in order 
to let the rest of the entity component system know when an entity has been added 
or removed: 

int EntityManager :: AddEntity (const Bitmask& l_mask, int l_id) { 
m_systems - >EntityModif ied (entity, l_mask) ; 

m_systems - >AddEvent (entity, (EventID) EntityEvent : : Spawned) ; 
return entity; 

} 


bool EntityManager :: RemoveEntity (const Entityldk l_id) { 

Message msg ( (MessageType ) EntityMessage : : Removed_Entity) ; 
msg . m_receiver = l_id; 
msg.m_int = l_id; 

m_systems->GetMessageHandler ( ) - >Dispatch (msg) ; 

... // Removing all components. 

} 

ing to need 

to be shared as well. Some of these classes, like the entity manager for example, 
have been slightly modified to serve as parents for derivatives of client and server 
code files 
ith the 

code structure. 

Building our game server 

In Chapter 13, We Have Contact! - Networking Basics, we took a look at a very basic 
ents 

ve a piece of 
doing all of the 
per and 
we're not 

simply exchanging text messages, there is going to be a lot more data being sent 
back and forth, as well as more calculation on the server side. 
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shots. It has 
ation as 

possible to remain efficient. After some testing and tweaking, a sweet spot can be 
found pretty easily. For this particular project, let's say that an entity snapshot will 
be sent once every 100 milliseconds, which will be defined in NetSettings . h: 

#def ine SNAPSHOT_INTERVAL 100 

Sending 10 snapshots a second is enough to keep the clients happy and the server 
maintaining a relatively low bandwidth. 

Additions to the entity component system 

In order to 
with 

the C_Attacker: 

class C_Attacker : public C_TimedComponentBase { 
public : 

C_Attacker() : C_TimedComponentBase (Component : : Attacker) , 

m_attacked (false) , m_knockback (0 . f ) , m_attackDuration ( 0 ) { } 
void Readln ( std : : stringstream& l_stream) { 
l_stream >> m_offset.x >> m_offset.y 

>> m_attackArea . width >> m_attackArea . height 
>> m_knockback >> m_attackDuration; 

} 


void SetAreaPosition (const sf : : Vector2f & l_pos) { 
mattackArea . lef t = l_pos.x; 
m_attackArea . top = l_pos.y; 

} 


const sf : : FloatRect& GetAreaOf Attack () { return m_attackArea; } 
const sf : : Vector2f & GetOffset(){ return m_offset; } 
bool HasAttacked ( ) { return m_attacked; } 

void SetAttacked (bool l_attacked) { m_attacked = l_attacked; } 
float GetKnockback ( ) { return m_knockback; } 
sf::Uint32 GetAttackDuration ( ) { return m_attackDuration; } 
private : 

sf : : FloatRect m_attackArea ; 
sf::Vector2f m_offset; 
bool m_attacked; 
float m_knockback; 
sf::Uint32 m_attackDuration; 

} ; 


[ 443 ] 



Come Play with Us! - Multiplayer Subtleties 


the 

entity's attack area and possible offset, a flag to check if the entity has hit something 
while attacking, the force of knockback that is to be applied to another entity being 
attacked by this one, and the duration of the attack. 

Implementing combat 

Entity-on-entity combat is going to be a fairly simple addition, since we already have 
a nice collision system in place. It only requires a few additional lines of code inside 
the EntityCollisions method: 

void S_Collision: : EntityCollisions ( ) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for (auto itr = m_entities . begin () ; 
itr != m_entities . end ( ) ; ++itr) 

{ 

for (auto itr2 = std :: next ( itr ) ; 
itr2 != identities . end ( ) ; ++itr2) 

{ 


C_Attacker* attackerl = entities- > 

GetComponent<C_Attacker> (*itr, Component: :Attacker) ; 
C_Attacker* attacker2 = entities- > 

GetComponent<C_Attacker> (*itr2 , Component: :Attacker) ; 
if (lattackerl && !attacker2){ continue; } 

Message msg ( (MessageType ) EntityMessage : : Being_Attacked) ; 
if (attackerl) { 

if (attackerl->GetAreaOfAttack ( ) . intersects ( 
collidable2->GetCollidable ( ) ) ) 

{ 

// Attacker-on-entity collision! 
msg . m_receiver = *itr2; 
msg.m_sender = *itr; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

} 

} 

if (attacker2 ) { 

if (attacker2->GetArea0fAttack ( ) . intersects ( 
collidablel->GetCollidable ( ) ) ) 

{ 

// Attacker-on-entity collision! 
msg . m_receiver = *itr; 
msg.m_sender = *itr2; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 
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} 

} 

} 

} 

} 

First, both entities being checked get their attacker components fetched. If neither 
of type 

Being Attacked is constructed. If the attacking entity's area of attach actually 
intersects the bounding box of another entity, this message is filled in with receiver 
and sender information and sent out. 

In order to process and react properly to these collisions, as well as update all the 
entities that have potential to be in combat, we're going to need a new system: 
S_Combat be 
o examine its 

header. Let's take a look at its constructor and destructor instead: 

S_Combat : : S_Combat (SystemManager* l_systemMgr) 

: S_Base (System: : Combat , l_systemMgr) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : Position) ; 
req . TurnOnBit ( (unsigned int ) Component : :Movable) ; 
req . TurnOnBit ( (unsigned int ) Component : : State) ; 
req . TurnOnBit ( (unsigned int ) Component : :Health) ; 
m_requiredComponents .push_back (req) ; 
req . ClearBit ( (unsigned int) Component : :Health) ; 
req . TurnOnBit ( (unsigned int ) Component : :Attacker) ; 
m_requiredComponents .push_back (req) ; 


m_systemManager- >GetMessageHandler ( ) - > 

Subscribe (EntityMessage : : Being_Attacked, this) ; 

} 

with a state, 
es to the 

Being_At tacked message in order to process attack area collisions. 
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Naturally, the same attack area cannot be positioned identically for all four directions 
that an entity is facing. Consider the following example: 



Repositioning the attack area for each entity based on its current direction is done 
inside the Update method of this system: 

void S_Combat :: Update (float l_dT) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for (auto &entity : m_entities) { 

C_Attacker* attack = entities-> 

GetComponent<C_Attacker> (entity, Component: :Attacker) ; 
if (! attack) { continue; } 

sf::Vector2f offset = attack- >GetOff set () ; 
sf : : FloatRect AoA = attack- >GetAreaOf Attack () ; 

Direction dir = entities- >GetComponent<C_Movable> 

(entity, Component: :Movable) - >GetDirection ( ) ; 
sf::Vector2f position = entities- >GetComponent<C_Position> 

(entity, Component: : Position) - >GetPosition ( ) ; 
if (dir == Direction :: Left) { offset. x -= AoA. width / 2; } 

else if (dir == Direction :: Right ){ of f set . x += AoA. width / 2; } 

else if (dir == Direction: :Up) {of fset .y -= AoA. height / 2; } 

else if (dir == Direction :: Down) {of fset . y += AoA. height / 2; } 

position -= sf : :Vector2f (AoA. width / 2, AoA. height / 2); 
attack- >SetAreaPosition (position + offset); 

} 

} 

If the current entity being checked has no c_Att acker component, the iteration is 
simply skipped. Otherwise, both the entity's area of attack and its offset are obtained, 
in addition to its current direction and position. In order to first center the attack 
ion. The offset 
ea of attack is 

moved to the latest position with it applied. 
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Let's take a look at a possible response to the message our collision system sends out: 

void S_Combat : :Notify (const Messagek l_message) { 
if ( ! HasEntity ( l_message . m_receiver ) | | 

! HasEntity ( l_message . m_sender ) ) 

{ 

return; 

} 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
EntityMessage m = (EntityMessage) l_message . m_type ; 
switch (m) { 

case EntityMessage: : Being_Attacked : 

C_Health* victim = entities - >GetComponent<C_Health> 
(l_raessage.m_receiver, Component: : Health) ; 

C_Attacker* attacker = entities->GetComponent<C_Attacker> 
(l_message.m_sender, Component: :Attacker) ; 
if ( Ivictim | | !attacker){ return; } 

S_State* StateSystem = m_systemManager- > 

GetSystem<S_State> (System: : State) ; 
if (StateSystem- >GetState (l_message .m_sender) != 

EntityState: : Attacking) 

{ 

return; 

} 

if (attacker- >HasAttacked ()) { return; } 

// Begin attacking. 

victim- >SetHealth ( (victim- >GetHealth ( ) > 1 ? 

victim- >GetHealth ( ) - 1 : 0) ) ; 

attacker- >SetAttacked ( true) ; 
if (! victim- >GetHealth ()) { 

StateSystem- >ChangeState (l_message .m_receiver, 

EntityState :: Dying, true); 

} else { 

Message msg ( (MessageType) EntityMessage : :Hurt) ; 
msg . mreceiver = l_message .m_receiver; 
m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

1 

// Knockback. 

Direction attackerDirection =entities->GetComponent<C_Movable> 
(l_message .m_sender, Component: :Movable) - >GetDirection ( ) ; 
float Knockback = attacker- >GetKnockback () ; 
sf::Vector2f KnockbackVelocity ; 
if (attackerDirection == Direction :: Left | j 
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attackerDirection == Direction :: Up) 

{ 

Knockback = -Knockback; 

} 

if (attackerDirection == Direction :: Left | 
attackerDirection == Direction :: Right ) 

{ 

KnockbackVelocity . x = Knockback; 

} 

else{ KnockbackVelocity . y = Knockback; } 
entities- >Get Component <C_Movable> 

(l_message .m_receiver, Component: :Movable)-> 
SetVelocity (KnockbackVelocity) ; 
break ; 

} 

} 


this 

message. If that's the case, the Being_Attacked message is processed by first 
obtaining the health component of the entity being attacked, as well as the attacker 
component of the aggressor. The state of the attacking entity is then checked. If it 
is not currently attacking or if the entity has already attacked something else, the 
method is terminated by returning. Otherwise, the attack is initiated by first reducing 
the victim's health by 1. The attacker is then flagged for having already attacked an 
entity. If the victim's health is at value 0, its state is changed to Dying. Otherwise, 
a Hurt message is dispatched. 

d back 

slightly, as it's being attacked. Both the attacker's direction and knockback force are 
obtained and a sf : :Vector2f variable, signifying the applied force is created. If 
the attacker is facing either left or up, the knockback value is inverted. Also, if the 
attacking entity is facing either left or right, the knockback is applied on the X axis. 
Otherwise, the Y axis is used. Then, the force is simply applied as velocity through 
the victim's c_Movable component. 

Server action timing 

ent is how 
ing, there 
an attack 
s comes in. 

For this, we're going to need the s_Timers system. Since it also doesn't have any 
additional methods other than the required ones, the class definition is not necessary. 
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Let's start by taking a look at the constructor and destructor of this system: 

S_Timers : : S_Timers (SystemManager* l_systemMgr) 

: S_Base (System: : Timers , l_systemMgr) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : State) ; 
req . TurnOnBit ( (unsigned int ) Component : :Attacker) ; 
m_requiredComponents .push_back (req) ; 
req . ClearBit ( (unsigned int) Component : :Attacker) ; 
req . TurnOnBit ( (unsigned int ) Component : :Health) ; 
m_requiredComponents .push_back (req) ; 

} 

tacker 

component, health component, or both. Nothing interesting happens here, so let's 
move on to the Update method that makes timing on the server side possible: 

void S_Timers :: Update ( float l_dT) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for (auto &entity : m_entities) { 

EntityState state = entities- >GetComponent<C_State> 

(entity, Component: : State) ->GetState() ; 
if (state == EntityState :: Attacking) { 

C_Attacker* attack = entities->GetComponent<C_Attacker> 
(entity, Component :: Attacker) ; 
attack- >AddToTimer ( sf : : seconds ( l_dT) ) ; 
if (attack- >GetTimer (). asMilliseconds ( ) < 
attack- >GetAttackDuration ( ) ) 

{ 

continue ; 

} 

attack- >Reset () ; 

attack- >SetAttacked ( false) ; 

} else if (state == EntityState :: Hurt | 
state == EntityState :: Dying) 

{ 

C_Health* health = entities-> 

GetComponent<C_Health> (entity, Component: :Health) ; 
health- >AddToTimer ( sf : : seconds ( l_dT) ) ; 
if ((state == EntityState :: Hurt && 

health- >GetTimer ( ) . asMilliseconds ( ) < 
health- >GetHurtDuration () ) | ( 

(state == EntityState :: Dying && 
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health- >GetTimer ( ) . asMilliseconds ( ) < 
health- >GetDeathDuration ( ) ) ) 

{ 

continue ; 

} 


health- >Reset () ; 

if (state == EntityState :: Dying) { 

Message msg ( (MessageType ) EntityMessage : : Respawn) ; 
msg . m^receiver = entity; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 
health- >ResetHealth ( ) ; 

} 

} else { continue; } 

m_systemManager- >GetSystem<S_State> (System: :State) -> 

ChangeState (entity, EntityState :: Idle , true) ; 

} 

} 

ee whether 

they have reached specific time values that are provided in the entity file. If the entity 
is in an attacking state, the attacker component is obtained and the elapsed time is 
e "attacked" flag 

is set back to false, making another attack possible. 

If the entity is in either the hurting or dying state, the respectful time values are 
checked against predetermined durations and the timer is reset once again. If the entity 
is actually in a dying state, a Re spawn message is sent out as well, in order to reset its 
animation, health and move the entity to a specific location where it "respawns". 

Server network system 

Handling entity networking on the server side can be made a lot easier by simply 
a by 

design. This is where the server network system comes in. 

Let's start with how entities are going to be controlled by players. In previous 
side. 

problematic to simply send out a bunch of messages whenever a client moves. It's 
much more efficient to simply keep track of a player's input state, as this simple 
structure demonstrates: 

struct Playerlnput{ 
int m_movedX; 
int m_movedY; 
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bool m_attacking; 

Playerlnput ( ) : m_movedX ( 0 ) , m_movedY(0), m_attacking (false) { } 


using PlayerlnputContainer = std : : unordered_map<EntityId, 
Playerlnput > ; 


The fi 
nput states 

to the server at a specific interval, which means we have the benefit of combining 
messages into neat packets, as well as process out redundant movement, such as 
going to 

be sending their attacking states. All of this information will be held in a container, 
which tethers it to a specific entity ID. 

Now, let's take a look at the header file of the network system we're going 
to implement: 

class S_Network : public S_Base{ 
public : 

S_Network (SystemManager* l_systemMgr) ; 

~S_Network ( ) ; 

void Update (float l_dT) ; 

void HandleEvent (const Entitylds l_entity, 
const EntityEventS l_event) ; 
void Notify(const Messages l_message) ; 

bool RegisterClientID (const Entitylds l_entity, 
const ClientlDS l_client) ; 
void RegisterServer ( Server* l_server) ; 

ClientID GetClientID (const Entitylds l_entity) ; 

Entityld GetEntitylD (const ClientlDS l_client) ; 

void CreateSnapshot (sf :: Packets l_packet) ; 

void UpdatePlayer ( sf :: Packets l_packet, const ClientIDS l_cid) ; 
private : 

PlayerlnputContainer m_playerlnput ; 

Server* m_server; 

} ; 
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As usual, we have the required methods implemented, as well as a few additional 
e have a few 
On top of 
and updating 

a specific client's information from an incoming packet. 

Implementing the network system 

Let's start with the constructor and destructor of the network system: 

S_Network: : S_Network (SystemManager* l_systemMgr) 

: S_Base (System: :Network, l_systemMgr) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : Client) ; 
m_requiredComponents .push_back (req) ; 

MessageHandler* messageHandler = 

m_systemManager- >GetMessageHandler ( ) ; 
messageHandler- >Subscribe (EntityMessage : : Removed_Entity , this) ; 
messageHandler- >Subscribe (EntityMessage : :Hurt, this) ; 
messageHandler- >Subscribe (EntityMessage : : Respawn, this) ; 

} 

This particular system is only going to require a single component: cclient. It also 
subscribes to entity removal, hurt, and respawn messages. 

Next, the Update method: 

void S_Network :: Update ( float l_dT) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for (auto &entity : m_entities) { 

auto& player = m_playerlnput [entity] ; 
if (player . m_movedX | | player . m_movedY) { 
if (player . m_movedX) { 

Message msg ( (MessageType ) EntityMessage : :Move) ; 
msg.m_receiver = entity; 

if (player . m_movedX > 0 ) {msg . m_int= ( int ) Direction :: Right ; } 
else { msg.m_int = ( int ) Direction :: Left ; } 
m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

} 


if (player . m_movedY) { 

Message msg ( (MessageType) EntityMessage : :Move) ; 
msg . m_receiver = entity; 
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if (player . m_movedY > 0 ) {msg . m_int= ( int ) Direction :: Down; } 
else { msg.m_int = ( int ) Direction :: Up ; } 
m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 


if (player . m_attacking) { 

Message msg ( (MessageType) EntityMessage : :Attack) ; 
msg . m_receiver = entity; 

m_systemManager- >GetMessageHandler ( ) - >Dispatch (msg) ; 

} 

} 


it to the 
te of 

a client's input. 

Next, let's deal with those three message types that this system is subscribed to: 

void S_Network : :Notify (const Messaged l_message) { 

if ( ! HasEntity ( l_message . m_receiver ) ) { return; } 

EntityMessage m = EntityMessage (l_message .m_type) ; 

if (m == EntityMessage :: Removed_Entity) { 
m_playerlnput . erase (l_message .m_receiver) ; 
return; 

} 

if (m == EntityMessage : :Hurt) { 
sf : ; Packet packet; 

StampPacket ( PacketType : :Hurt, packet) ; 
packet << l_message . m_receiver ; 
m_server- >Broadcast (packet) ; 
return; 

} 

if (m == EntityMessage :: Respawn) { 

exposition* position = m_systemManager- >GetEntityManager ( ) - > 
GetComponent<C_Position> (l_message .m_receiver, 

Component: : Position) ; 
if (!position){ return; } 
position- >Set Posit ion (64. f, 64 . f ) ; 
position- >SetElevation ( 1) ; 

} 

} 
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First, if the entity is being removed, the player input information of the 
about an entity 
lients to notify 

them of an entity taking damage. Lastly, an entity respawn message is handled by 
resetting its position and elevation to some pre-defined values. These coordinates can 
easily be randomized or read in from the map file, but for demonstration purposes 
this works just fine. 

need to have 

a method that allows us to express that relationship by binding the two values 
together, as shown here: 

bool S_Network :: RegisterClientID (const Entityldk l_entity, 
const ClientID& l_client) 

{ 

if ( ! HasEntity ( l_entity) ) { return false; } 

m_systemManager- >GetEntityManager ( ) - >GetComponent<C_Client> 
(l_entity, Component: : Client) ->SetClientID (l_client) ; 
return true; 

} 

t, it's obtained 

through the entity manager and used in exactly that manner. 

The network class is also going to need access to an instance of the Server class, 
hence the following method: 

void S_Network :: RegisterServer (Server* l_server) { 
m_server = l_server; 

} 

Next, a few methods of convenience for obtaining client and entity IDs: 

ClientID S_Network :: GetClientID ( const Entityld& l_entity) { 

if (! HasEntity ( l_entity) ) { return (ClientID) Network :: NullID ; } 
return m_systemManager- >GetEntityManager ( ) -> 

GetComponent<C_Client> (l_entity, Component: : Client) -> 

GetClientID () ; 

} 

Entityld S_Network :: GetEntitylD ( const ClientID& l_client) { 
EntityManager* e = m_systemManager- >GetEntityManager ( ) ; 
auto entity = std: : find_if (m_entities .begin () , m_entities . end ( ) , 

[&e, &l_client] (Entitylds id) { 
return e- >GetComponent<C_Client> 
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(id, Component :: Client) ->GetClientID ( ) == l_client; 

}); 

return (entity != m_entities . end ( ) ? 

*entity : (Entityld) Network :: NullID) ; 

} 

Snapshot creation itself also deserves its own method: 

void S_Network :: CreateSnapshot ( sf :: Packets l_packet){ 

sf : : Lock lock (m server- >GetMutex ( ) ) ; 

ServerEntityManager* e = 

( Serve rEntityManager* ) m_systemManager- >GetEntityManager ( ) ; 
StampPacket ( PacketType : : Snapshot, l_packet) ; 
l_packet << sf : : Int32 (e->GetEntityCount ( ) ) ; 
if (e- >GetEntityCount ( ) ) { 

e- >DumpEntityInf o (l_packet) ; 

} 

} 

Because we're accessing entity information that could be changed, the server mutex 
the packet 
. If the 

number is above zero, a DumpEntitylnfo method is invoked. This method is 
defined within our ServerEntityManager class and will be covered shortly. 

Lastly, let's handle the incoming player update packets: 

void S_Network :: UpdatePlayer ( sf :: Packets l_packet, 
const ClientlDS l_cid) 

{ 

sf : : Lock lock (m server- >GetMutex ( ) ) ; 

Entityld eid = GetEntitylD ( l_cid) ; 
if (eid == -1) { return; } 
if ( ! HasEntity (eid) ) { return; } 
sf::Int8 entity_message ; 
m_playerlnput [eid] .m_attacking = false; 
while (l_packet >> entity_message) { 
switch (entity_message) { 
case sf ; : Int8 (EntityMessage : :Move) : 

{ 

sf::Int32 x = 0, y = 0; 
l_packet >> x >> y; 
m_playerlnput [eid] . m_movedX = x; 
m_playerlnput [eid] . m_movedY = y; 
break ; 
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} 

case sf : : Int8 (EntityMessage : : Attack) : 

{ 

sf::Int8 attackState; 
l_packet >> attackState; 

if (attackState) { m_playerlnput [eid] .m_attacking = true; } 
break ; 

} 

} 

sf::Int8 delim = 0; 

if (! (l_packet >> delim) | | delim != 

( sf ; : Int8 ) Network ; : PlayerUpdateDelim) 

{ 

std::cout << "Faulty update!" << std::endl; 
break ; 

} 

} 

} 

locked 
is is done by 

obtaining the entity ID and checking its validity in the next two lines. A local variable 
named entity_message is then created in order to hold the message type that the 
client is going to be sending to us. The attack state of the entity is then set to false 
by default and iterating over the packet's information begins. 

Encountering a Move message is dealt with by extracting the X and Y values from 
the packet and overwriting our player movement information for the given entity 
with them. The Attack message has one less value to worry about. The player's 
m_attacking flag is set to true if the incoming player state contains anything 
else but zero. 

Server entity and system management 

The components and systems supported on the server side are obviously going to 
both ends 

help out a great deal by allowing the base class to remain unmodified, while the 
derivatives can deal with side-specific logic. Let's take a look at our simple extension 
to the EntityManager class that runs on the server side: 

ServerEntityManager : : ServerEntityManager (SystemManager* l_sysMgr) 

: EntityManager (l_sysMgr) 

{ 

AddComponentType<C_Position> (Component : : Position) ; 
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AddComponentType<C_State> (Component : : State) ; 
AddComponentType<C_Movable> (Component : :Movable) ; 
AddComponentType<C_Controller> (Component : : Controller) ; 
AddComponentType<C_Collidable> (Component : :Collidable) ; 
AddComponentType<C_Client> (Component : : Client) ; 
AddComponentType<C_Health> (Component : : Health) ; 
AddComponentType<C_Name> (Component : :Name) ; 
AddComponentType<C_Attacker> (Component : :Attacker) ; 

} 


t types 

here. It's the client's job to deal with those. 

This class will also be useful when creating entity snapshots. All of the entity 
information is dumped into a provided instance of sf : : Packet by using this method: 

void ServerEntityManager :: DumpEntitylnfo ( sf :: Packets l_packet) { 
for (auto Sentity : m_entities) { 

l_packet << sf :: Int32 (entity . first) ; 

EntitySnapshot snapshot; 

snapshot .m_type = entity . second . m_type ; 

const autos mask = entity . second. m_bitmask; 

if (mask . GetBit ( (unsigned int ) Component :: Position) ) { 

C_Position* p = GetComponent<C_Position> (entity . first , 

Component: : Position) ; 
snapshot .m_position = p- >GetPosition ( ) ; 
snapshot . m_elevation = p- >GetElevation ( ) ; 

} 

if (mask . GetBit ( (unsigned int) Component :: Movable) ) { 

C_Movable* m = GetComponent<C_Movable> (entity . first , 

Component: :Movable) ; 
snapshot ,m_velocity = m- >GetVelocity ( ) ; 
snapshot . m_acceleration = m- >GetAcceleration ( ) ; 
snapshot . redirection = sf : : Uint8 (m- >GetDirection ( ) ) ; 

} 

if (mask . GetBit ( (unsigned int) Component :: State) ) { 

C_State* s = GetComponent<C_State> (entity . first , 

Component: : State) ; 

snapshot ,m_state = sf : : Uint8 ( s- >GetState ( ) ) ; 

} 

if (mask . GetBit ( (unsigned int ) Component :: Health) ) { 

C_Health* h = GetComponent<C_Health> (entity . first , 

Component: : Health) ; 
snapshot . m_health = h- >GetHealth ( ) ; 
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} 

if (mask . GetBit ( (unsigned int) Component :: Name) ) { 
C_Name* n = GetComponent<C_Name> (entity . first , 
Component : : Name ) ; 
snapshot . mname = n- >GetName ( ) ; 

} 

l_packet << snapshot; 

} 

} 


The entity ID is written into the packet instance first. An EntitySnapshot variable 
is created afterwards, and it is filled with relevant component information, provided 
these components exist at all. Once that's done, the snapshot instance is written to the 
packet, which is made incredibly easy thanks to its overloaded << and >> operators. 

terns that 
are added: 

ServerSystemManager ; : ServerSystemManager ( ) { 

AddSystem<S_Network> (System: : Network) ; 

AddSystem<S_State> (System: : State) ; 

AddSystem<S_Control> (System: : Control) ; 

AddSystem<S_Movement> (System: :Movement) ; 

AddSystem<S_Timers> (System : :Timers) ; 

AddSystem<S_Collision> (System: : Collision) ; 

AddSystem<S_Combat> (System: :Combat) ; 

} 

Similar to what we did for components, we simply exclude anything graphical or 
sound related. 

Main server class 

Similar to the client side's Game class, a supervisor object is going to be needed on 
map, entity, 

and server managers, and the Server class itself in a new class, simply called World. 
Let's start by taking a look at the header file: 

class World{ 
public : 

World ( ) ; 

-World ( ) ; 

void Update(const sf::Time& l_time) ; 
void HandlePacket ( sf : : IpAddress& l_ip, 
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const PortNumber& l_port, const PacketID& l_id, 
sf::Packet& l_packet, Server* l_server) ; 
void ClientLeave (const ClientID& l_client) ; 
void CommandLine ( ) ; 

bool IsRunningO; 
private : 

sf::Time m_tpsTime; 
sf::Time m_serverTime ; 
sf::Time m_snapshotTimer ; 
sf : : Thread m_commandThread; 

Server m_server; 

ServerSystemManager m_systems; 

ServerEntityManager m_entities; 
bool m_running; 

Map m_map ; 

unsigned int m_tick; 
unsigned int m_tps; 

} ; 

Similar to Game, it has an Update method where all of the time-related magic is going 
g a client 

leaving, and processing command-line input. 

Data member wise, we're looking at a few sf : : Time instances for keeping track 
of the current server time, as well as delivery time for snapshots. A sf : : Thread 
instance for the command line is also quite handy to have around. 

Last but not least, the m_tpsTime, m_tick and m_tps data members exist for the 
simple convenience of measuring the update rate on the server. The number of 
wn and 

resolving performance issues. 

Implementing the world class 

uctor: 

World :: World () : m_server ( &World : : HandlePacket , this), 

m_commandThread ( &World : : CommandLine , this) , m_entities (nullptr) , 
m_map (&m_entities) , m_tick(0), m_tps(0), m_running (false) 

{ 

if (! m_server . Start ()) { return; } 
m_running = true; 

m_systems . SetEntityManager (&m_entities) ; 
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m_entities . SetSystemManager (&m_systems) ; 
m_map . LoadMap ( "media /Maps /mapl . map" ) ; 

m_sys terns . GetSystem<S_Collision> (System: : Collision) -> 
SetMap (&m_map) ; 

m_systems . GetSystem<S_Movement> (System : :Movement) -> 
SetMap (&m_map) ; 

m_sys terns . GetSystem<S_Network> (System: : Network) - > 
RegisterServer ( &m_server) ; 

m_server . BindTimeoutHandler ( &World : : ClientLeave , this) ; 
m_commandThread . launch ( ) ; 

} 


World :: -World () { m_entities . SetSystemManager (nullptr) ; } 

Our Serverer 
constructor, 

we first attempt to start the server and catch a possible failure in an if statement. 
Upon a successful start, the m_running flag is set to true and both the entity 
game 

map is then loaded and relevant systems are provided with its instance. After our 
network system is made available with an instance of Server, the ClientLeave 
method is fed in as the timeout handler and the command line thread is launched. 

Upon destruction of the World class, all we really have to worry about is taking away 
the entity manager's access to the system manager. 

Next, let's keep the action rolling by updating everything: 

void World :: Update (const sf::Time& l_time) { 

if ( !m_server. IsRunning () ) { mrunning = false; return; } 

m__serverTime += l_time; 

m_snapshotTimer += l_time; 

m_tpsTime += l_time; 

m_server . Update (l_time) ; 

m server . GetMutex ( ) .lock() ; 

m_systems . Update (l_time . asSeconds ()); 

m server . GetMutex ( ) . unlock () ; 

if (m_snapshotTimer . asMilliseconds ( ) >= SNAPSHOT_INTERVAL) { 

sf:: Packet snapshot; 

m_systems . GetSystem<S_Network> (System : : Network) -> 

CreateSnapshot (snapshot) ; 
m_server . Broadcast ( snapshot ) ; 
m_snapshotTimer = sf : :milliseconds (0) ; 

} 
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if (m_tpsTime >= sf : : milliseconds (1000) ) { 
m_tps = m_tick; 
m_tick = 0; 

m_tpsTime = sf : : milliseconds (0) ; 

} else { 

++m_tick; 



The server instance is first checked for having stopped. If that's the case, the world 
class itself is stopped and the Update method is returned from. Otherwise, all of our 
time values are updated alongside the server class. The system manager's Update 
The server 
otentially 
be changed. 

t has exceeded 

the snapshot interval. With that being the case, a snapshot packet is created and 
filled in by using the CreateSnapshot method of s_Network. The packet is then 
ro. 



Ticks Per Second (TPS) are measured by increasing the m_tick data 
member every update, provided the TPS timer hasn't exceeded one 
second. If that's the case, m_tps is assigned the value of m_tick, which 
in turn gets set back to zero, alongside the TPS timer. 


Handling incoming packets is the next piece of the puzzle: 

void World :: HandlePacket ( sf :: IpAddressS l_ip, 

const PortNumberS l_port, const PacketlDS l_id, 
sf:: Packets l_packet, Server* l_server) 

{ 

ClientID id = l_server- >GetClientID (l_ip , 1 port) ; 
PacketType type = (PacketType) l_id; 
if (id >= 0) { 

if (type == PacketType : disconnect) { 

ClientLeave (id) ; 

l_server- >RemoveClient ( l_ip, l_port) ; 

} else if (type == PacketType : :Message) { 

II ... 

} else if (type == PacketType :: PlayerUpdate) { 

m_systems . GetSystem<S_Network> (System: :Network) -> 
UpdatePlayer ( l_packet , id) ; 

} 
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} else { 

if (type != PacketType :: Connect ) { return; } 
std: : string nickname; 

if ( ! (l_packet >> nickname) ) { return; } 

ClientID cid = l_server- >AddClient ( l_ip, l_port) ; 
if (cid == -1) { 

sf : : Packet packet; 

StampPacket ( PacketType : :Disconnect, packet) ; 
l_server- >Send ( l_ip, l_port, packet); 
return; 

} 

sf : : Lock lock (m server . GetMutex ( ) ) ; 

sf::Int32 eid = m_entities .AddEntity ( "Player" ) ; 
if (eid == -1) { return; } 

m_sys terns . GetSystem<S_Network> (System: : Network) - > 

RegisterClientID (eid, cid); 

C_Position* pos = m_entities . GetComponent<C_Position> 

(eid, Component :: Position) ; 
pos->SetPosition (64 . f , 64. f); 

m_entities . GetComponent<C_Name> (eid, Component: :Name) -> 

SetName (nickname) ; 
sf:: Packet packet; 

StampPacket ( PacketType : : Connect, packet) ; 
packet << eid; 

packet << pos->GetPosition ( ) .x << pos - >GetPosition ( ) . y ; 
if ( ! l_server- >Send (cid, packet) ) { 

std::cout << "Unable to respond to connect packet!" 

<< std : : endl ; 
return; 

} 

} 

} 

The client ID is first obtained from the originating IP address and port number. If 
a client with that information exists, we're interested in three packet types that can 
nvoking the 

ClientLeave method with the client ID passed in as the only argument. Next, the 
actual client is removed from the server class. 

The next packet type. Message, is left unimplemented for now. We're not going 
Id be 

implemented in the future. Following that is the player update packet type, in which 
. We have 

already covered this. 
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client ID, 
we attempt 
If that fails, 

this method is returned from. Next, the client information is added and its success is 
checked by analyzing the returned client ID. In case of a failure, a Disconnect packet 
Otherwise, 

the server mutex is locked and we attempt to add a new player entity. Failure to 
ent ID is 
d player 

entity is set to some pre-defined values. The name component of the player entity 
is also adjusted to reflect the entered nickname. At this point, a connect packet is 
ell as its spawn 

position. The packet is then sent out to our new client. 

Leaving the server is a much simpler procedure in comparison to this. Let's take 
a look: 

void World :: ClientLeave ( const ClientID& l_client) { 
sf : : Lock lock (m server . GetMutex ( ) ) ; 

S_Network* network = m_systems . 

GetSystem<S_Network> (System: :Network) ; 
m_entities . RemoveEntity (network- >GetEntityID ( l_client ) ) ; 

} 

work 

system is then obtained and the RemoveEntity method of our entity manager is 
invoked with the return value of network system's GetEntitylD method. This 
effectively removes the entity. 

Implementing some basic commands on the server side proves to be more than 


void World: : CommandLine ( ) { 

while (m_server . IsRunning ( ) ) { 
std: : string str; 
std : : get line ( std : : cin, str); 
if (str == "terminate")! 
m_server . Stop ( ) ; 
m_running = false; 
break; 

} else if (str == "disconnectall " ) { 

std::cout << "Disconnecting all clients..." << std::endl; 
m_server . DisconnectAll () ; 

sf : : Lock lock (m_server . GetMutex ( ) ) ; 

m_entities . Purge ( ) ; 
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} else if (str . f ind ( " tps" ) != std :: string :: npos ) { 

std::cout << "TPS: " << m_tps << std::endl; 

} else if (str == "clients") { 

std::cout << m_server . GetClient Count ( ) 

<< " clients online:" << std:: endl; 
std::cout << m_server . GetClientList ( ) 

<< std : : endl ; 

} else if (str == "entities") { 

std::cout << "Current entity count: " 

<< m_entities . GetEntityCount ( ) << std: : endl; 


} 

. Next, the 

command line is prompted to obtain a line of input. The first command we process 
is "terminate". This stops the server and breaks out of the command line loop, 
which is helpful. The following command disconnects every single client and purges 
all entities that currently exist. Notice that the server mutex gets locked before the 
• T yP in g 

in "clients"ir 

IP addresses, port numbers, and latency values. Lastly, the "entities" command 
simply prints out the number of entities that are currently in the world. 

The last and defi 
status of the world: 

bool World :: IsRunning () { return m_running; } 

Server entry point 

of our 

Server_Main . cpp file: 

#include "World. h" 

int main ( ) { 

World world; 
sf::Clock clock; 
clock . restart ( ) ; 

while (world . IsRunning ()) { 

world. Update (clock . restart 0 ) ; 

} 

return 0 ; 

} 
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It couldn't get simpler than this. A new instance of the World class is created, 
alongside a clock that is promptly restarted. Our main while loop is entered with the 
condition that the world instance has to keep running. It gets updated every iteration 
with the return value of clock . restart ( ) . After the loop is terminated, zero is 
returned to end the program successfully. 

t's ready 

to handle some incoming connections: 


I nooning port: 5600. Outgoing port: 50979 
Beginning to listen... 

Loading a map: nedia/Maps/napl . map 

Map Loaded? 

clients 


2 

clients online: 


z 

Client IP:POBT 

Ping 

0 

127.0.0.1:50980 

0ms . 

1 

127.0.0.1:50981 

0ms . 


Total data sent: 9kB. Total data receiued: 3kB 


This by itself is, of course, completely useless without the client that draws all of the 
he next major 
task on our list. 

Developing the game client 

n client- 

side details and spoil ourselves a little with pretty visuals that always yield that 
sense of accomplishment a lot quicker than anything that runs in the background. 
Let's start by creating the client's own version of NetSettings . h: 

#def ine NE T_REND E R_D E LAY 100 // ms. 

#def ine PLAYER_UPDATE_INTERVAL 50 // ms 

y between 
ly we're 
second 
server. 

50 milliseconds gives us plenty of time to gather a few input states and let the 
server know what's going on. 


[ 465 ] 





Come Play with Us! - Multiplayer Subtleties 


Entity component system expansions 

As in the case of the server, additional components and systems are necessary if we 
tions to the 

client entity component system are going to serve an entirely different purpose. It's 
layers in the 

game. We're going to shoot for something like this: 






In order to easily maintain these glyphs floating above an entity, we're going 
posed 

to be rendered: 

class C_UI_Element : public C_Base{ 
public : 

C_UI_Element ( ) : C_Base (Component : :UI_Element) , 

m_showHealth ( false) , m_showName (false) {} 
void Readln ( std : : stringstream& l_stream) { 
l_stream >> m_offset.x >> m_offset.y; 

} 


const sf : : Vector2f & GetOffset(){ return m_offset; } 

void Setoff set (const sf : : Vector2f & l_offset) { m_offset = l_offset; } 

void SetShowHealth (bool l_show) { m_showHealth = l_show; } 
void SetShowName (bool l_show) { m_showName = l_show; } 
bool ShowHealth ( ) { return m_showHealth; } 
bool ShowName ( ) { return m_showName ; } 
private : 

sf::Vector2f m_offset; 
bool m_showHealth; 
bool m_showName ; 

} ; 
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The c_Ul_Element component will read in two offset values, one for X and one for Y, 
from the entity file. This way, characters of different sizes can define their own rules 
of where this information will appear. We also included a couple of Boolean flags in 
case the health or name information ever needs to be disabled for some reason. 

new system 

that actually makes something happen: 

class S_CharacterUI : public S_Base{ 
public : 

S_CharacterUI (SystemManager* l_systemMgr) ; 

~S_CharacterUI ( ) ; 

void Update (float l_dT) ; 

void HandleEvent (const Entityldk l_entity, 
const EntityEventk l_event) ; 
void Notifyfconst Messages l_message) ; 

void Render (Window* l_wind) ; 
private : 

sf::Sprite m_heartBar; 
sf::Text m_nickname; 
sf : : RectangleShape m_nickbg; 
sf::Vector2u m_heartBarSize ; 

} ; 

Note that this system has a Render method. We're not only going to update the 
is includes 

a sprite that will be bound to whatever texture is chosen to represent health, an 
instance of sf : : Text that will hold the entity's name, a rectangle background that 
of the 

health bar texture. 

With that out of the way, let's start implementing this system! 

S_CharacterUI : : S_CharacterUI (SystemManager* l_systemMgr) 

: S_Base (System: : Character_UI , l_systemMgr) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : Position) ; 
req . TurnOnBit ( (unsigned int ) Component : :UI_Element) ; 
req . TurnOnBit ( (unsigned int ) Component : :Health) ; 
m_requiredComponents .push_back (req) ; 
req . ClearBit ( (unsigned int) Component : :Health) ; 
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req . TurnOnBit ( (unsigned int ) Component : :Name) ; 
m_requiredComponents .push_back (req) ; 

ClientSystemManager* mgr = (ClientSystemManager* ) m_systemManager ; 
mgr- >GetTextureManager ( ) - >RequireResource ( "HeartBar " ) ; 
mgr- >GetFontManager ( ) - >RequireResource ( "Main" ) ; 
sf::Texture* txtr = mgr- >GetTextureManager ( ) - > 

GetResource ( "HeartBar " ) ; 
txtr- >setRepeated ( true) ; 
m_heartBarSize = txtr- >getSize ( ) ; 
m_heartBar . setTexture ( *txtr ) ; 
m_heartBar . setScale ( 0 . 5f , 0.5f) ; 

m_heartBar . setOrigin (m_heartBarSize . x / 2, m_heartBarSize . y) ; 

m_nickname . setFont ( *mgr- >GetFontManager ( ) - >GetResource ( "Main" ) ) ; 

m_nickname . setCharacterSize (9); 

m_nickname . setColor ( sf : :Color: :White) ; 

m_nickbg . setFillColor ( sf :: Color ( 100 , 100, 100, 100)); 

} 

The first order of business here is, of course, setting up the component requirements, 
n addition 

to some combination of the health and name components. The rest of the constructor 
ealth bar 

texture is set to be repeated so we can represent any health value. The actual texture 
is only the size of a single heart. 

The resources for these elements obviously have to be released when they're no 
longer needed. That's where the destructor comes in: 

S_CharacterUI : : ~S_CharacterUI ( ) { 

ClientSystemManager* mgr = 

(ClientSystemManager* ) m_systemManager ; 
mgr- >GetTextureManager ( ) - >ReleaseResource ( "HeartBar " ) ; 
mgr- >GetFontManager ( ) - >ReleaseResource ( "Main" ) ; 

} 

Lastly, the most important part of this system is contained within the Render method: 

void S_CharacterUI :: Render (Window* l_wind) { 

EntityManager* entities = m_systemManager- >GetEntityManager ( ) ; 
for (auto kentity : m_entities) { 

C_Health* health = entities-> 

GetComponent<C_Health> (entity, Component: : Health) ; 

C_Name* name = entities -> 

Ge t Component <C_Name> (entity, Component: :Name) ; 

C_Position* pos = entities- > 
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GetComponent<C_Position> (entity , Component: : Position) ; 
C_UI_Element* ui = entities-> 

GetComponent<C_UI_Element> (entity, Component: :UI_Element) ; 
if (health) { 

m_heartBar . setTextureRect (sf : : IntRect ( 0 , 0 , 
m_heartBarSize . x * health- >GetHealth () , 
m_heartBarSize . y) ) ; 
m_heartBar . setOrigin ( ( 

m_heartBarSize . x * health- >GetHealth ()) /2 , 
m_heartBarSize . y) ; 

m_heartBar . setPosition (pos- >GetPosition ( ) +ui->GetOff set ( ) ) ; 
l_wind- >GetRenderWindow ( ) - >draw (m_heartBar ) ; 

} 

if (name) { 

m_nickname . setstring (name- >GetName ( ) ) ; 

m_nickname . setOrigin (m_nickname . getLocalBounds (). width / 2, 
m_nickname . getLocalBounds (). height / 2); 
if (health) { 

m_nickname . setPosition (m_heartBar . getPosition ( ) . x, 
m_heartBar . getPosition ( ) . y - (m_heartBarSize . y) ) ; 

} else { 

m_nickname . setPosition (pos- >GetPosition ( ) + 
ui->GetOffset () ) ; 

} 

m_nickbg. setSize (sf : :Vector2f ( 

m_nickname . getGlobalBounds (). width + 2, 
m_nickname . getCharacterSize ( ) + 1) ) ; 
m_nickbg . setOrigin (m_nickbg . getSize (). x / 2, 
m_nickbg.getSize () .y / 2); 

m_nickbg . setPosition (m_nickname . getPosition (). x + 1, 
m_nickname . getPosition (). y + 1) ; 
l_wind- >GetRenderWindow ( ) - >draw (m_nickbg) ; 
l_wind- >GetRenderWindow ( ) ->draw (m_nickname) ; 



For each entity, we obtain all four components that we're going to be working with, 
exist 

without the other one present, both of them must be checked before we commit 
to rendering them. 
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The health bar portion is drawn by first resetting the texture rectangle of the sprite. 
Its width is changed to the result of multiplying the width of a single heart in the 
texture by the health value an entity has. The Y value is left unchanged. The origin 
of the sprite is then changed to be in the middle of it on the X axis and on the very 
bottom of the Y axis. Its position is then set to that of the entity's, but with the UI 
self, this allows 

us to represent ridiculous amounts of health: 



When an entity's name is rendered, the sf : : Text instance is first set up by changing 
the string and its origin is manipulated to be exactly in the middle. Since we want 
checking 

if the health was rendered is necessary. 

If the health component is present, the name's position is obtained from the 
m_heartBar data member. The Y value of that position is modified by subtracting 
the height of the health bar in order to render the player name on top. Otherwise, 
the name's position is set to match the entity with the offset included. The name 
background is then set up to be slightly larger than the text that it will be drawn 
behind and its origin is set to the exact center. The position of the name background is 
slightly offset by a single pixel from the position of the actual name. The values used 
here can be perfected by simply trying out different things and getting the feel for the 
best result. 

Lastly, the background and the entity's name are drawn in that order on screen. 

Network class and interpolation 

t all. Even 

if we get them to move, you will quickly notice that due to the delay between the 
the screen, 

rather than walking. A little more work has to be done on the client side in order 
rpolation. 

Consider the following illustration: 
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What is interpolation? It's an estimation between two known data points. There are 
many different types of interpolation out there, all with a different philosophy of 
use. For our purposes, interpolating data simply comes down to finding a weighted 
average between two values at a given time. In the preceding diagram, we have two 
snapshots representing different places in time. Interpolating helps us find the state 
of an entity somewhere in the middle of those two snapshots, and, in turn, smooths 
out their movement by adjusting attributes such as position, velocity, and acceleration 
based on the estimation, rather than actual snapshot data. 

Finding a value at a specific point in time between two snapshots can be expressed 
this way: 


value(t x ) = (i^e 




*( t x- t l)) + value ( t 1 ) 


A value we want to find at a given time, tx, is simply the difference of the value 
between both snapshots divided by the difference in time, multiplied by the time 
that has passed since the first snapshot and then added to the value of the first 
snapshot. In code, it can be expressed like this: 

template<class T> 

inline T Interpolate (const sf::Int32& T1 , const sf::Int32& T2 , 
const T& Tl_val, const T& T2_val , const sf::Int32& T_X) 

{ 

return ( ( (T2_val - Tl_val) / (T2 - Tl) ) * (T_X - Tl)) + Tl_val ; 

} 

ypes, 

as well as comparing two snapshots together, would be useful: 

void InterpolateSnapshot (const EntitySnapshotk l_sl, 
const sf::Int32& Tl , const EntitySnapshotk l_s2 , 
const sf::Int32& T2 , EntitySnapshotk l_target, 
const sf::Int32& T_X) ; 
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bool CompareSnapshots ( const EntitySnapshot& l_sl, 

const EntitySnapshot& l_s2, bool l_position = true, 
bool l_physics = true, bool l_state = true) ; 

We're fine 
our data types: 

using SnapshotMap = std : : unordered_map<EntityId, EntitySnapshot> ; 
struct SnapshotDetails{ 

SnapshotMap m_snapshots; 

} ; 

using SnapshotContainer = std: :map<sf : : Int32 , SnapshotDetails> ; 
using OutgoingMessages = std : : unordered_map<EntityMessage , 
std: : vector<Message» ; 

All of the snapshots are first stored with the entity ID being the key. The actual map 
itself is being held by a SnapshotDetails struct, which may prove to be useful 
e entity data 
s the key 
dered map. 

What's the benefit, you may ask. The regular map type may be a little bit slower, 
but it automatically sorts its entries by key. This means that newer snapshots will 
11 become 

apparent when we're performing entity interpolation. 

t of container 
case, an 

unordered map works just fine, 
ok: 


class S_Network : public S_Base{ 
public : 

S_Network (SystemManager* l_systemMgr) ; 
~S_Network ( ) ; 

void Update (float l_dT) ; 

void HandleEvent (const Entityldk l_entity, 
const EntityEvent& l_event) ; 
void Notifyfconst Messages^ l_message) ; 

void SetClient (Client* m_client) ; 

void SetPlayerlD (const Entityldk l_entity) ; 
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void AddSnapshot (const Entityldk l_entity, 
const sf::Int32& l_timestamp, 

EntitySnapshot& l_snapshot) ; 
void SendPlayerOutgoing ( ) ; 
void ClearSnapshots ( ) ; 
private : 

void ApplyEntitySnapshot (const Entityldk l_entity, 
const EntitySnapshot& l_snapshot, 
bool l_applyPhysics) ; 

void Perf ormlnterpolation ( ) ; 

SnapshotContainer m_entitySnapshots ; 

Entityld m_player; 

OutgoingMessages m_outgoing; 

Client* m_client; 

sf::Time m_playerUpdateTimer ; 

} ; 


Apart from the normal methods a system has to implement, we have a few setters for 
registering a client instance, as well as keeping track of the entity ID that our client is 
going to be controlling as a player. A few helper methods for adding a received entity 
snapshot, as well as sending out player messages to the server also exist to make life 
just a little bit easier. For our private method selection, we have a total of two: one for 
applying a specific snapshot to an entity and another for performing interpolation. 
This is met by a standard number of data members that are responsible for containing 
received snapshots, keeping track of the player ID, containing outgoing messages to 
the server before they're sent out, and having access to the client instance. To top 
that off, we're going to use another sf : : Time data type in order to keep track of time 
passage for sending player updates to the server. 

Implementing the client network class 

Before we get to actually implementing the network system, let's complete the last 
s: 


void InterpolateSnapshot (const EntitySnapshotk l_sl, 
const sf::Int32& Tl, const EntitySnapshotk l_s2 , 
const sf : : Int32& T2 , EntitySnapshotk l_target, 
const sf::Int32& T_X) 

{ 

l_target . redirection = l_s2 .in direction; 
l_target . mjiealth = l_s2 .mhealth; 
l_target . mjiame = l_s2 .mname ; 
l_target .m_state = l_sl . m_state ; 
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l_target . m_elevation = l_sl . melevation; 

l_target . m_position . x = Interpolate<float> ( 

Tl, T2 , l_sl . m_position . x, 1 s2.m position.x, T_X); 
l_target . m_position . y = Interpolate<float> ( 

Tl, T2 , l_sl .m_position.y, l_s2 . m_position . y , T_X); 

l_target . m_velocity . x = Interpolate<f loat> ( 

Tl, T2 , l_sl . m_velocity . x, l_s2 . m_velocity . x, T_X) ; 
l_target . m_velocity . y = Interpolated loat> ( 

Tl, T2 , l_sl .m_velocity .y, l_s2 . m_velocity . y , T_X); 

l_target . m_acceleration . x = Interpolated loat> ( 

Tl, T2 , l_sl . m_acceleration . x, l_s2 . m_acceleration . x, T_X); 
l_target . m_acceleration . y = Interpolate<float> ( 

Tl, T2 , l_sl . m_acceleration . y , l_s2 . m_acceleration . y , T_X) ; 

} 

We begin by overwriting some values that don't need to be interpolated. Note that 
vailable 

information from the second entity snapshot, rather than the first. This provides 
st of the 

snapshot data, we use our handy Interpolate function, which provides a smooth 
transition between the two updates. 

together, so 

we can know if any data has changed. CompareSnapshots comes to the rescue here: 

bool CompareSnapshots ( const EntitySnapshot& l_sl, 
const EntitySnapshotk l_s2, bool l_position, 
bool l_physics, bool l_state) 

{ 

if (l_position && ( l_sl . m_position != I_s2 . m_position | 
l_sl . m_elevation != I_s2 . m_elevation) ) 

{ return false; } 

if (l_physics && (l_sl .m_velocity != I_s2 . m_velocity || 
l_sl . m_acceleration != I_s2 . m_acceleration | | 
l_sl . redirection != I_s2 . redirection) ) 

{ return false; } 

if (l_state && (l_sl .m state != I_s2 .m_state) ) 

{ return false; } 
return true; 

} 
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e. All we really 
tity. Three 
which 

data is relevant. 

With this out of the way, we can finally begin implementing the network system 
class, starting, of course, with the constructor and destructor: 

S_Network: : S_Network (SystemManager* l_systemMgr) 

: S_Base (System: :Network, l_systemMgr) , m_client (nullptr) 

{ 

Bitmask req; 

req . TurnOnBit ( (unsigned int ) Component : : Client) ; 
m_requiredComponents .push_back (req) ; 

m_systemManager- >GetMessageHandler ( ) - > 

Subscribe (EntityMessage : :Move, this) ; 
m_systemManager- >GetMessageHandler ( ) - > 

Subscribe (EntityMessage : :Attack, this) ; 
m_playerUpdateTimer = sf : tmilliseconds (0) ; 

} 

client 

components in this system. Messages for entity movement and attacks are also 
r on. 

Next up, we have the Update method: 

void S_Network :: Update ( float l_dT) { 
if (!m_client){ return; } 
sf : : Lock lock (m client- >GetMutex ( ) ) ; 
m_playerUpdateTimer += sf :: seconds ( l_dT) ; 
if (m_playerUpdateTimer . asMilliseconds ( ) >= 

PLAYER_UPDATE_INTERVAL ) 

{ 

SendPlayerOutgoing ( ) ; 

m_playerUpdateTimer = sf : :milliseconds (0) ; 

} 

Perf ormlnterpolation ( ) ; 

} 
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t class. 

The 

SendPlayerOutgoing method is then invoked and the timer is reset if enough 
method of 
eping this 
looking 

code and allows early return while interpolating. 

ou will 
see here: 

void S_Network : :Notify (const Message& l_message) { 
if ( ! HasEntity ( l_message . m_receiver ) | \ 

lmessage . m receiver != m_player) 

{ 

return ; 

} 

if (l_message . m_type == (MessageType) EntityMessage :: Attack && 
m_outgoing . find (EntityMessage :: Attack) != m_outgoing . end ( ) ) 

{ 

return ; 

} 

m_outgoing [ (EntityMessage) l_message . m_type] . 
emplace_back (l_message) ; 

} 

container, 
check is 

performed in case an attack message is received. There really is no point of having 
multiple attack messages in this container at the same time, so the Notify method 
e already 

exists in the container. 

Next, we have some helper methods: 

void S_Network :: SetClient (Client* l_client) {m_client = l_client;} 
void S_Network :: SetPlayerlD ( const Entityld& l_entity) { 
m_player = l_entity; 

} 

void S_Network : :AddSnapshot ( const Entityld& l_entity, 

const sf::Int32& l_timestamp, EntitySnapshot& l_snapshot) 

{ 

sf : : Lock lock (mclient- >GetMutex ( ) ) ; 

auto i = m_entitySnapshots . emplace ( l_timestamp , 

SnapshotDetails 0); 

i . f irst->second. m_snapshots . emplace (l_entity, l_snapshot) ; 

} 


[ 476 ] 



Chapter 14 


There's nothing too special going on here. One thing to note is that when a new 
aking 

of snapshots, let's look at how one could be applied to an entity: 

void S_Network : : ApplyEntitySnapshot (const Entityld& l_entity, 
const EntitySnapshot& l_snapshot, bool l_applyPhysics ) 

{ 

ClientEntityManager* entities = 

(ClientEntityManager* ) m_systemManager- >GetEntityManager ( ) ; 
C_Position* position = nullptr; 

C_Movable* movable = nullptr; 

S_Movement* movement_s = nullptr; 

S_State* state_s = nullptr; 

C_Health* health = nullptr; 

C_Name* name = nullptr; 

sf : : Lock lock (mclient- >GetMutex ( ) ) ; 

if (position = entities - >GetComponent<C_Position> ( l_entity. 
Component : : Position) ) 

{ 

position- >Set Posit ion (l_snapshot ,m_position) ; 
position- >SetElevation ( l_snapshot . m_elevation) ; 

} 

if (l_applyPhysics) { 

if (movable = entities- >GetComponent<C_Movable> ( l_entity. 
Component; : Movable) ) 

{ 

movable - >SetVelocity (l_snapshot .m_velocity) ; 
movable->SetAcceleration (l_snapshot . m_acceleration) ; 

} 

} 

if (movement_s = m_systemManager- > 

GetSystem<S_Movement> (System : ;Movement) ) 

movement_s- >SetDirection ( l_entity , 

(Direction) l_snapshot . m_direction) ; 

} 

if (state_s = m_systemManager-> 

GetSystem<S_State> (System: : State) ) 

{ 

state_s->ChangeState (l_entity, 

(EntityState) l_snapshot . m_state , true) ; 

} 

if (health = entities - >GetComponent<C_Health> ( l_entity, 
Component: : Health) ) 
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{ 

health- >SetHealth ( l_snapshot . m_health) ; 

} 

if (name = entities - >GetComponent<C_Name> (l_entity, 

Component : :Name) ) 

{ 

name- >SetName (l_snapshot .m_name) ; 

} 

} 

After we obtain a pointer to the entity manager and set up empty pointers to various 
components that the entity snapshot might contain information about, the client 
fully, 

by first attempting to retrieve a valid component address inside the if statements. 
This method also takes in a flag to let it know whether physics information, such as 
acceleration or velocity, should be applied, which can come in handy. 

, and it is 

responsible for sending player updates to the server: 

void S_Network: : SendPlayerOutgoing ( ) { 
sf::Int32 p_x = 0, p_y = 0; 
sf : : Int8 p_a = 0 ; 

for (auto &itr : m_outgoing) { 

if (itr. first == Ent i tyMess age :: Move) { 
sf::Int32 x = 0, y = 0; 
for (auto &message : itr. second) { 

if (message . mint == ( int ) Direction :: Up) { --y; } 
else if (message . m_int == ( int ) Direction :: Down) { ++y; } 

else if (message . m_int == ( int ) Direction :: Left ) { --x; } 

else if (message . m_int == ( int ) Direction :: Right ) { ++x; } 

} 

if (!x && !y) { continue; } 
p_x = x; p_y = y; 

} else if (itr. first == EntityMessage :: Attack) { p_a = 1; } 

} 


sf:; Packet packet; 

StampPacket ( PacketType : : PlayerUpdate , packet) ; 
packet << sf :: Int8 (EntityMessage : :Move) 

<< p_x << p_y << sf :: Int8 (Network :: PlayerUpdateDelim) ; 
packet << sf :: Int8 (EntityMessage :: Attack) 

<< p_a << sf :: Int8 (Network :: PlayerUpdateDelim) ; 
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m_client- >Send (packet ) ; 
m_outgoing . clear ( ) ; 

} 


We begin by setting up some local variables that are going to be holding the number 
of times our player has moved in the X and Y directions. A smaller variable is also 
set up for the attack state. The next step is to iterate over all outgoing messages and 
process each type individually. In a case of a Move type, every single one of them is 
counted. If an Attack message is found, the attack state is simply set to 1. 

The last step is, of course, sending this information out. A new packet is 

state information is then fed into the packet. Notice that we're adding in the 
PlayerUpdateDelim value at the end of each update type. Enforcing specific 
communication rules as such decreases the chances of our server processing 

message container is cleared for the next time. 


void S_Network: : Perf ormlnterpolation ( ) { 

if (m_entitySnapshots . empty ()) { return; } 

ClientEntityManager* entities = 

(ClientEntityManager* ) m_systemManager- >GetEntityManager ( ) ; 
sf::Time t = m_client - >GetTime ( ) ; 
auto itr = ++m_entitySnapshots . begin () ; 
while (itr != m_entitySnapshots . end ( ) ) { 
if (m_entitySnapshots . begin ()- >first <= 
t . asMilliseconds ( ) - NET_RENDER_DELAY && 

itr->first >= t . asMilliseconds ( ) - NET_RENDER_DELAY) 

{ 

auto Snapshotl = m_ent itySnap shot s . begin () ; 

auto Snapshot2 = itr; 

bool SortDrawables = false; 

for (auto snap = Snapshotl- >second . m_snapshots . begin () ; 
snap != Snapshotl->second.m_snapshots . end ( ) ; ) 

{ 

if ( ! entities->HasEntity (snap->first) ) { 

if (entities- >AddEntity ( snap- > second . m_type , 
snap->first) == ( int) Network :: NullID) 

{ 

std::cout << "Failed adding entity type: " 

<< snap- >second . m_type << std::endl; 
continue ; 

} 

ApplyEntitySnapshot (snap->f irst , snap- >second, true); 
++snap; 
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continue ; 

} 

auto snap2 =Snapshot2 - >second . m_snapshots . f ind ( 
snap->first) ; 

if (snap2 == Snapshot2 - >second . m_snapshots . end ( ) ) { 
sf : : Lock lock (mclient- >GetMutex ( ) ) ; 

entities- >RemoveEntity ( snap- >f irst ) ; 

snap = Snapshotl- >second .m_snapshots . erase (snap) ; 

continue ; 

} 

EntitySnapshot i_snapshot ; 

InterpolateSnapshot ( snap- >second, Snapshotl - >f irst , 
snap2->second, Snapshot2 - >f irst , 

i_snapshot, t . asMilliseconds ( ) - NET_RENDER_DELAY) ; 

ApplyEntitySnapshot (snap->first, i_snapshot, true); 
if ( ! CompareSnapshots ( snap- >second, snap2 - >second, 
true, false, false)) 

{ 

SortDrawables = true; 

} 

++snap; 

} 

if (SortDrawables) { 

m_systemManager- >GetSystem<S_Renderer> 

(System: :Renderer) - >SortDrawables ( ) ; 

} 

return; 

} 

m_entitySnapshots . erase (m_entitySnapshots . begin ( ) ) ; 
itr = ++m_entitySnapshots . begin () ; 

} 

} 

having any 
ely. If we 
ontainer and 

finding two snapshots that we're currently between (time wise). Normally, this 
wouldn't be a likely outcome, but keep in mind that we're rendering things slightly 
in the past: 


t 



1 * 

t 

current 

#1 i#2 #3 i 

, : Render delay ! 

►! 
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The benefit of rendering slightly in the past is that we will actually have more data 

it out and 

ndered 

everything in real time. This delay is represented by the net_render_delay macro. 
Once we fi 

SortDrawables is set up to keep track of whether or not we need to worry about 
entities 

from the first (earlier) snapshot are then iterated over. Our first concern is making 
sure that an entity that exists in the snapshot also exists on our client. If it doesn't, a 
new entity is created from the type that the snapshot provides. All of its information 
is then applied to the newly created entity and we skip the current iteration of the 
snapshot loop as there's no need to interpolate anything. 

The next step is making sure that the entity that exists in the earlier snapshot also 
exists in the later one, so an attempt to find it in the second snapshot container is 
and the 
he snapshot 
reason to 

interpolate once again, 
w instance of 

EntitySnapshot is created. This is going to be our target for holding interpolated 
data. interpolateSnapshot is then called with both snapshots and their time 
values, as well as the target snapshot and the current time with the interpolation delay 
factored in is passed in as arguments. After the target snapshot is filled in with the 
interpolated data, it is applied to the current entity. We also want to compare both 
snapshots we're interpolating between and set the SortDrawables variable to true if 
they have different positions. After all of the entity interpolation code, this variable is 
mponents if 

it was indeed set to true at some point. 

One last thing to take away from this is that if the time checking conditional in the 
very first loop ends up not being satisfied, the first element in the snapshot container 
ensuring a proper 
disposal of irrelevant snapshots. 
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Client entity and system management 

Quite predictably, we're going to have different types of components and systems 
nt types: 

ClientEntityManager : : ClientEntityManager (SystemManager* l_sysMgr , 
TextureManager* l_textureMgr) : EntityManager ( l_sysMgr ) , 
m_textureManager ( l_textureMgr ) 

{ 

AddComponentType<C_Position> (Component : : Position) ; 
AddComponentType<C_State> (Component : : State) ; 
AddComponentType<C_Movable> (Component : :Movable) ; 
AddComponentType<C_Controller> (Component: : Controller) ; 
AddComponentType<C_Collidable> (Component : :Collidable) ; 
AddComponentType<C_SpriteSheet> (Component : : SpriteSheet) ; 
AddComponentType<C_SoundEmitter> (Component : : SoundEmitter ) ; 
AddComponentType<C_SoundListener> (Component : : SoundListener ) ; 
AddComponentType<C_Client> (Component: : Client) ; 
AddComponentType<C_Health> (Component: : Health) ; 
AddComponentType<C_Name> (Component: :Name) ; 
AddComponentType<C_UI_Element> (Component: :UI_Element) ; 

} 

t's implement 
he renderable 
components it may have: 

int ClientEntityManager: :AddEntity( 

const std :: strings l_entityFile, int l_id) 

{ 


while ( std : : getline ( f ile , line) ) { 

} else if (type == "Component")! 
keystream >> ‘component; 

if ( component - >GetType () == Component :: SpriteSheet) { 
C_SpriteSheet* sheet = (C_SpriteSheet* ) component ; 
sheet ->Create (m_textureManager) ; 

} 


} 


} 
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to emphasize 

that the highlighted snippet does not exist on the server side at all, yet is necessary 
here. 

Next, the client's version of a system manager: 

class ClientSystemManager : public SystemManager { 
public : 

ClientSystemManager (TextureManager* l_textureMgr , 

FontManager* l_fontMgr) ; 

-ClientSystemManager ( ) ; 

TextureManager* GetTextureManager ( ) ; 

FontManager* GetFontManager ( ) ; 

void Draw (Window* l_wind, unsigned int l_elevation) ; 
private : 

TextureManager* m_textureMgr ; 

FontManager* m_f ontMgr; 

} ; 

raphics. 

here. 

The constructor of our client system manager handles adding systems that are 
relevant to the client performing as intended: 

ClientSystemManager : : ClientSystemManager ( 

TextureManager* l_textureMgr , FontManager* l_fontMgr) 

: m_textureMgr ( l_textureMgr ) , m_f ontMgr ( l_f ontMgr ) 

{ 

AddSystem<S_State> (System: : State) ; 

AddSystem<S_Control> (System: : Control) ; 

AddSystem<S_Movement> (System: :Movement) ; 

AddSystem<S_Collision> (System: : Collision) ; 
AddSystem<S_SheetAnimation> (System: : SheetAnimation) ; 
AddSystem<S_Network> (System: : Network) ; 

AddSystem<S_Sound> (System: : Sound) ; 

AddSystem<S_Renderer> (System : :Renderer) ; 

AddSystem<S_CharacterUI> (System: : Character_UI ) ; 

} 

systems 
network 
ur own. 
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Naturally, getters for texture and font managers would be useful on this side: 

TextureManager* ClientSystemManager : : GetTextureManager ( ) { 
return m_textureMgr ; 

} 

FontManager* ClientSystemManager: : GetFontManager ( ) { 
return m_fontMgr; 

} 

Lastly, we have a few systems that need to render something on screen: 

void ClientSystemManager :: Draw (Window* l_wind, 
unsigned int l_elevation) 

{ 

auto itr = msystems . find (System: : Renderer) ; 
if(itr != m_systems . end ( ) ) { 

S_Renderer* system = (S_Renderer* ) itr- >second; 
system- >Render ( l_wind, l_elevation) ; 

} 

itr = m_systems . find (System: : Character_UI ) ; 
if (itr != msystems . end ( ) ) { 

S_CharacterUI* ui = (S_CharacterUI* ) itr- >second; 
ui- >Render ( l_wind) ; 

} 

} 

o overlay 

their names and health graphics on top of that. 

Putting the pieces into place 

ithin the 
confiting with 
the header file: 

class State_Game : public BaseState{ 

private : 

Map* m_gameMap; 
int m_player; 

Client* m_client; 

} ; 
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After making sure that the game state has a pointer to a Client instance, we must 
provide a way for the game to handle incoming packets: 

void State_Game :: HandlePacket ( const PacketID& l_id, 
sf::Packet& l_packet, Client* l_client) 

{ 

ClientEntityManager* eragr = m_stateMgr-> 

GetContext () - >m_entityManager ; 

PacketType type = (PacketType) l_id; 
if (type == PacketType: : Connect ) { 
sf : : Int32 eid; 
sf::Vector2f pos; 

if ( ! (l_packet >> eid) | | ! (l_packet >> pos.x) | \ 

! (l_packet >> pos.y)) 

{ 

std::cout << "Faulty CONNECT response!" << std::endl; 
return; 

} 

std::cout << "Adding entity: " << eid << std::endl; 
mclient- >GetMutex ( ) .lock() ; 
emgr- >AddEntity (" Player " , eid) ; 
emgr- >GetComponent<C_Position> 

(eid, Component: : Position) - >SetPosition (pos ) ; 
m client- >GetMutex ( ) .unlockO ; 
m_player = eid; 

m_stateMgr- >GetContext () - >m_systemManager- > 

GetSystem<S_Network> (System : : Network) - >SetPlayerID (m_player ) ; 

emgr- >AddComponent (eid. Component: : SoundListener) ; 

return ; 

} 


if ( ! m_client - >IsConnected ( ) ) { return; } 

switch (type) { 

case PacketType :: Snapshot : 

{ 

sf::Int32 entityCount = 0; 

if ( ! (l_packet >> entityCount) ) { 

std::cout << "Snapshot extraction failed." 

<< std : : endl ; 
return; 

} 

sf : : Lock lock (mclient- >GetMutex ( ) ) ; 

sf::Int32 t = m_client- >GetTime ( ) . asMilliseconds ( ) ; 

for (unsigned int i = 0; i < entityCount; ++i) { 
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sf : : Int32 eid; 

EntitySnapshot snapshot; 

if (! (l_packet >> eid) | | ! (l_packet >> snapshot) ) { 

std : : cout << "Snapshot extraction failed." 

<< std : : endl ; 
return; 

} 

m_stateMgr- >GetContext ( ) - >m_systemManager- > 
GetSystem<S_Network> (System: :Network) -> 

AddSnapshot (eid, t, snapshot); 

} 

break ; 

} 

case PacketType :: Disconnect : 

{ 

m_stateMgr- >Remove (StateType : :Game) ; 
m_stateMgr- >SwitchTo (StateType : :MainMenu) ; 
std::cout << "Disconnected by server!" << std::endl; 
break ; 

} 

case PacketType :: Hurt : 

{ 

Entityld id; 

if (!(l_packet >> id) ) { return; } 

Message msg ( (MessageType ) EntityMessage : :Hurt) ; 
msg . m_receiver = id; 

m_stateMgr- >GetContext () - >m_systemManager- > 

GetMessageHandler ( ) - >Dispatch (msg) ; 
break ; 

} 

} 

} 

er the client 
cted from the 

packet, the client mutex is locked while the player entity is added and its position 
is updated. The entity ID of our player is then stored in the m player data member 
line of code 

in this segment before we return. After the entity is successfully constructed, we're 
one single 

sound listener on the client side, which is our player. This means that the player . 
entity file does not have its own sound listener component anymore. Instead, 
it must be added here in order to have correct audio positioning. 
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rocess snapshot, 

hurt, and disconnect packets. If a snapshot is received, we first attempt to read the 
nt mutex is then 
of entity 

snapshots. A new for loop is then constructed to run for each individual entity in the 
he network 

system for later processing. 

If a disconnect packet is received from the server, we simply remove the game state 
e entity ID 

in it is extracted and a Hurt message that is to be received by that entity is created 
and sent out. 

to have it try 

to establish a connection to the server upon creation: 

void State_Game : : OnCreate ( ) { 

m_client- >Setup (&State_Game : : HandlePacket , this) ; 
if (m_client- >Connect ( ) ) { 

m_stateMgr- >GetContext () - >m_systemManager- > 

GetSystem<S_Network> (System: :Network) ->SetClient (m_client) ; 


evMgr- >AddCallback (StateType : :Game, " Player_Attack" , 

&State_Game: : PlayerAttack, this) ; 

} else { 

std::cout << "Failed to connect to the game server!" 

<< std : : endl ; 

m_stateMgr- >Remove (StateType : :Game) ; 
m_stateMgr- >SwitchTo (StateType : :MainMenu) ; 

} 

} 

ct to the server 
his point. If the 

connection attempt was successful, we can start initializing our data members and 
he player 

attack button being pressed. If the connection wasn't successful, the game state is 
removed and we switch back to the main menu state instead. 
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If the game state is removed, some cleanup is in order: 

void State_Game : : OnDestroy ( ) { 
m_client- >Disconnect ( ) ; 
m_client- >UnregisterPacketHandler ( ) ; 

S_Network* net = m_stateMgr- >GetContext ( ) - > 

m_systemManager- >GetSystem<S_Network> (System: :Network) ; 
net->ClearSnapshots ( ) ; 
net->SetClient (nullptr) ; 
net->SetPlayerID ( ( int ) Network : :NullID) ; 

evMgr->RemoveCallback (StateType : :Game, " Player_Attack" ) ; 


} 

st now also 
ng used by 

the client class. The network system is also cleared of all snapshots it may currently 
. The player 

attack callback is also removed here. 

Naturally, we're going to want to alter the Update method of the game state a little 
as well: 

void State_Game :: Update ( const sf::Time& l_time) { 
if ( ! m_client - >IsConnected ( ) ) { 

m_stateMgr- >Remove (StateType : :Game) ; 
m_stateMgr- >SwitchTo (StateType : :MainMenu) ; 
return; 

} 

SharedContext* context = mstateMgr- >GetContext ( ) ; 

UpdateCamera ( ) ; 

m_gameMap- >Update (l_time . asSeconds ( ) ) ; 

{ " 

sf : : Lock lock (mclient- >GetMutex ( ) ) ; 

context - >m_systemManager- >Update ( l time . asSeconds ( ) ) ; 

} 

} 

The connection status of our client is first checked. Not being connected means we 
get to exit the game state and switch back to the main menu once again. Otherwise, 
we continue on with the updating. Note the curly brackets surrounding the system 
manager update call. They create a scope for any variables defined inside, which 
is useful for locking the client mutex with a sf : : Lock instance, as it will fall out of 
scope once we're outside the brackets, in turn unlocking it. 
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Drawing things on screen also needs a slight adjustment: 

void State_Game : : Draw ( ) { 

if ( ! m_gameMap ) { return; } 
sf : : Lock lock (mclient- >GetMutex ( ) ) ; 
for (int i = 0; i < Sheet :: Num_Layers ; ++i){ 
m_gameMap- >Draw ( i ) ; 

m_stateMgr- >GetContext () - >m_systemManager- > 

Draw (m_stateMgr- >GetContext () ->m_wind, i) ; 

} 

} 

ities on 

different elevations in a for loop. We don't want another thread to manipulate 
any data that we may be currently accessing. 

Lastly, the player attack button being pressed needs to be handled like this: 

void State_Game : : PlayerAttack (EventDetails* l_details) { 

Message msg ( (MessageType) EntityMessage : :Attack) ; 
msg . m_receiver = m_player; 

m_stateMgr- >GetContext ( ) - >m_systemManager- > 

GetMessageHandler ( ) - >Dispatch (msg) ; 

} 

ystem has a 
message type 
t to the server 
at a specific interval. 

Main menu adjustments 

mall 

ur server 

information! Let's fix that by modifying the main menu interface file: 

Interface MainMenu MainMenu . style 0 0 Immovable NoTitle "Main menu" 
Element Label Title 100 0 MainMenuTitle . style "Main menu:" 

Element Label IpLabel 0 32 DefaultLabel . style "IP:" 

Element TextField IP 18 32 MainMenuTextf ield . style "127.0.0.1" 
Element Label PortLabel 150 32 DefaultLabel . style "Port:" 

Element TextField PORT 175 32 MainMenuTextf ield. style "5600" 

Element Label NameLabel 50 56 DefaultLabel . style "Nickname:" 

Element TextField Nickname 105 56 MainMenuTextf ield. style "Player" 
Element Label Play 0 80 MainMenuLabel . style "CONNECT" 
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Element Label Disconnect 0 116 MainMenuLabel . style "DISCONNECT" 

Element Label Credits 0 152 MainMenuLabel . style "CREDITS" 

Element Label Quit 0 188 MainMenuLabel . style "EXIT" 

new text 

fields and some text labels that go next to them to let the user know what they're 
for. This is how server information, as well as the player nickname, is going to be 
entered. Let's make this happen by adding a few callbacks for the new buttons: 

void State_MainMenu : : OnCreate ( ) { 

SetTransparent (true) ; // Transparent for rendering. 

SetTranscendent (true) ; // Transcendent for updating. 

eMgr- >AddCallback (StateType : :MainMenu, "MainMenu_Play" , 
&State_MainMenu : : Play , this); 

eMgr- >AddCallback (StateType : : MainMenu, "MainMenu_Disconnect " , 
&State_MainMenu : : Disconnect, this) ; 
eMgr- >AddCallback (StateType : :MainMenu, "MainMenu_Quit " , 
&State_MainMenu : : Quit , this); 

} 

void State_MainMenu ; :OnDestroy() { 

gui->RemoveInterface (StateType : :MainMenu, "MainMenu") ; 
eMgr- >RemoveCallback (StateType : :MainMenu, "MainMenu_Play" ) ; 
eMgr- >RemoveCallback (StateType : :MainMenu, "MainMenu_Disconnect " ) ; 
eMgr- >RemoveCallback (StateType : :MainMenu, "MainMenu_Quit " ) ; 

} 

is interface 

each time the menu state is activated: 

void State_MainMenu Activate () { 

GUI_Interf ace* menu = m_stateMgr- >GetContext ( ) - > 

m_guiManager- >GetInterf ace (StateType : :MainMenu, "MainMenu") ; 
if (m_stateMgr- >HasState (StateType : :Game) ) { 

// Resume 

menu- >GetElement ( " Play" ) - >SetText ( "Resume" ) ; 
menu- >GetElement ( "Disconnect " ) - >SetActive (true) ; 
menu- >GetElement ( " IP" ) - > Set Active (false) ; 
menu- >GetElement ( " PORT" ) - >Set Active (false) ; 
menu- >GetElement ( " IpLabel " ) - >SetActive (false) ; 
menu- >GetElement ( " Port Label " ) - >SetActive (false) ; 
menu- >GetElement ( " Name Label " ) - >SetActive (false) ; 
menu- >Get Element ( "Nickname" ) - >Set Active (false) ; 
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} else { 

// Play 

menu- >GetElement ( " Play") - >SetText (" CONNECT" ) ; 
menu- >Get Element ( "Disconnect " ) - >Set Active (false) ; 
menu- >GetElement ( " IP" ) - >SetActive (true) ; 
menu- >GetElement (" PORT" ) - >SetActive (true) ; 
menu- >Get Element ( " IpLabel " ) - >SetActive (true) ; 
menu- >Get Element ( " Port Label " ) - >SetActive (true) ; 
menu- >GetElement ( "NameLabel " ) ->SetActive (true) ; 
menu- >GetElement ( "Nickname " ) - >SetActive (true) ; 



in our 

interface to reflect the current state of our connection, 
t buttons: 

void State_MainMenu: : Play (EventDetails* l_details) { 
if ( ! m_stateMgr- >HasState (StateType : : Game) ) { 

GUI_Interf ace* menu = m_stateMgr- >GetContext ( ) - > 

m_guiManager- >GetInterf ace (StateType : :MainMenu, "MainMenu") ; 
std: : string ip = menu- >GetElement ( " IP" ) - >GetText ( ) ; 

PortNumber port = std::atoi( 

menu- >GetElement ( " PORT" ) - >GetText ( ) . c_str ( ) ) ; 
std::string name = menu- >GetElement ( "Nickname" ) ->GetText () ; 
m_stateMgr- >GetContext ( ) - >m_client- > 

SetServerlnf ormation (ip, port); 
m_stateMgr- >GetContext ( ) - >m_client- >SetPlayerName (name) ; 

} 

m_stateMgr- >SwitchTo (StateType : :Game) ; 

} 

void State_MainMenu :: Disconnect (EventDetails* l_details) { 
m_stateMgr- >GetContext ( ) - >m_client- >Disconnect ( ) ; 

} 

The first check in the Play method is made to ensure the text field information is 
ton that's 
game state 
information 
ither mean 
in is used, or 

that it's simply brought back to being the dominant application state. 
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The disconnect button callback only invokes the client's Disconnect method, which 
in turn results to the game state terminating itself. 

With that, we have a fully functional 2D multiplayer game where players can attack 
one another! 



Summary 

y to take, 
managed 
at's where 
at either 

one of the three projects we covered is finished. In fact, this is only the beginning. 

t you can 

ayer skins 

transitions for 

much more. 

Undoubtedly, you must have your own ideas and mechanics in mind that should 
p the flow 

going and get to coding! 
omes of 

the world we created is in your hands, so make it a good one. Goodbye! 
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